Re: Messages being received out of order

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Even MTU is constant value, e.g. for ethereal it's 1500 bytes, you can't be
sure how much your data will be send in one packet, because if IP header is
constant value, TCP header size depends on the option's in it, so your data
vary. Just use or data length before your data or end limiter
at the end of your data.
Arkady

"Angus" <nospam@xxxxxxxxx> wrote in message
news:uHsX39rcHHA.4864@xxxxxxxxxxxxxxxxxxxxxxx
So it maybe that the order received IS correct but that how I deal with
the
data in recv is the problem?

On the server, I send in buffers of up to 8192. Is this too big? Should
I
be sending only in buffers of eg up to MTUSIZE eg 1400 bytes? Will that
make a difference? ie make it more reliable?

Are you saying that tcp assures you that if you send data1, data2 then
data3
these packets will be received by the recipient in that order?

If so, then I only need to fix my client - specifically the recv handling?

Angus




"Dave Lowther" <davel@xxxxxxxxx> wrote in message
news:eXlExorcHHA.4888@xxxxxxxxxxxxxxxxxxxxxxx
"Angus" <nospam@xxxxxxxxx> wrote in message
news:Ob8VuNrcHHA.4392@xxxxxxxxxxxxxxxxxxxxxxx
Hello

I have built a client server network program communicating over tcp
sockets.
Up till now the amount of data passing between client and server has
been
quite small. But now I am passing data of 2500 bytes or so and I am
finding
that sometimes the client receives the data out of order.

That can not happen with TCP, something else must be going wrong.

I am trying to work out the best way to deal with this. Is MTU size
something to do with it.

No.

What is the best way to deal with this socket programming issue?

You need to do something like put a header on each chunk of data you
send,
e.g. length (of data that follows header).

Do not assume that you get 1::1 relationship between send() and recv(),
e.g. you may do send() - 10K bytes, recv() 1.5K bytes, next recv() may
give you the remaining 8.5K, or less.

Bottom line is your recv() code should be prepared to recv() anything
from 1 byte, up to the size of the buffer you passed to recv().

HTH.

Dave.






.

Relevant Pages

  • Incorrect TCP checksum problem
    ... I am using TCP ... If I retry the connection from the client it doesn't ... It recovers when I restart the server application. ... however the TCP header data is somehow damaged. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Messages being received out of order
    ... On the server, I send in buffers of up to 8192. ... Are you saying that tcp assures you that if you send data1, ... then I only need to fix my client - specifically the recv handling? ...
    (microsoft.public.win32.programmer.networks)
  • Re: Incomplete lines received by a socket
    ... > be returned by a single recvcall in the client. ... TCP does not transport ... This is usually done by performing the recv() in a loop until ... so you say the recv may be in a loop. ...
    (comp.unix.programmer)
  • Re: Problem with writing fast UDP server
    ... it likely means you have reached your ethernet bandwidth ... frames) to achieve your desired results. ... Keep in mind TCP is stream based, not datagram based so you may need ... On your client, make the following changes. ...
    (comp.lang.python)
  • Re: Advice on a multithreaded netisr patch?
    ... cache, and the link layer will take a cache miss on the front of the ... netstat packets per second and my application's TCP ... header flowid field, and use that instead of the hash for work placement. ...
    (freebsd-net)