"Marc" <
XXXX@XXXXX.COM>writes
Quote
Hello,
I need to send data pakets of 1400 bytes from a TIdTCPClient to a
TIdTCPServer.
OK. These 'packets' are discrete data items associated with your client and
server applications, eg. a record of size 1400. Is this right?
Quote
If I send one paket, the server receives two, one with 1024bytes and one
with the rest.
OK. first of all, TCP does not transfer packets, it transfers octet, (byte)
streams. TCP has no concept of any application-layer protocol units or any
sort of reconrd more complex than a byte. If you send 1400 bytes from a
client and make read calls at the connected server, the OS/TCP-stack may
return 1400 bytes in one call, 1 byte in 1400 calls, or anything in between.
It's just a stream of bytes, nothing else is guaranteed. TCP will
concatenate and.or split up your APUs in any way it feels like, merely
guaranteeing that all *bytes*sent will be received in the same order.
Quote
As the data pakets are created by different threads and coming in very
fast,
the server sometimes mixes them up and doesn't put the right ones
together.
TCP has no concept of application-level data structures, only byte streams.
If you have multiple threads sending different Application Protocol Units,
(packets is a very ambiguous term, best not used), along one client<>server
connection, it is up to you to serialise the sends, either by queueing the
APUs to a single thread or using a critical section or similar synchro
operations.
Quote
So first I receive two pakets with the small rest and then the two
1024bytes
pakets.
I thought that the max paket size has something to do with the MTU, which
is
1500 on both machines. So is there any way to increase the paket size to
more than 1024 bytes?
Or any other easy way to ensure the right pakets are combined?
If your application wants to send anything other than a byte-stream, you
have to add your own protocol on top of TCP. This protocol must be able to
cope with a byte-stream as input and generate APUs as output.
I have to admit that I don't quite understand your exact problem. Indy
tends to make it easy to read data items of varying sizes from the input
stream by providing various calls that return data of a given size from Indy
internal buffers. Surely, there is an Indy read call that can take a length
parameter of 1400 and so will always return your complete APU? I don't
like such protocols myself because they cannot recover at all if a malformed
APU is received, eg. some dodgy router somewhere shoves in an extra null at
the end of one APU to make it 1401 bytes long, so stuffing the alignment and
receipt of all subsequent APUs. Nevertheless, some developers persist in
doing fixed-size read calls and, aparrently, keep connections going for
quite some time before blowing up <g>
Rgds,
Martin