problems with multiple send and recv between client and serv

[vonaldinjo]

HI,

I have a client program which sends text messages to server running in another machine over gigabit ethernet. Server simply reads those and resends back to the client. I am using TCP socket in stream mode.

The problem is that after one cycle of sending and receiving at client and server, in the second round the client does not seem to be getting the message resend by the server. In the third round, the client gets what the server ought to have send in the second round and in the fourth round the client does not receive anything and so on.

By the way, it works fine in datagram mode.

The OS in Linux. Any limitations with recv() function in stream mode?

vondinjo

[RobSeace]

Well, not a "limitation", per se, but more just a misunderstanding
on your part, I think... Since it's a stream-oriented connection,
not a datagram-oriented one, that's all you can rely on: having
a bi-directional character stream... If you send a "message"
down the stream, there's no guarantee of exactly how it'll arrive
and be read by the remote side... Perhaps it'll get split into
multiple smaller packets on the wire, and only half of it will
arrive initially, so that the receiver just reads that first half; then,
the second half arrives later, perhaps at the same time as part
or all of a second message, so that when the receiver reads
again, he now gets the last half of the first message AND
some/all of the second message, all at once... See what I'm
saying? All you have is a simple character stream; there are
no divisions between separate "messages"; in fact, there's no
such concept as separate "messages"... If your protocol needs
the idea of separate messages, and it needs to run over TCP,
then YOU have to design such handling in yourself... Eg: the
typical method to accomplish this is to prefix all messages by
a fixed-length header, which gives the length of the upcoming
message; then, make sure all of your read()/recv() calls are
constructed such that they always read an exact, fixed amount...
(Ie: make them loop and retry when they get a short read, and
reduce the max to read as appropriate... You'll find example
code for such read()/recv() cover functions in other messages
here, I'm sure...) Because, on their own read()/recv() will
normally just give you whatever is queued up and waiting to be
read, with no regard for message-boundries, because there is
no such thing, as far as it's concerned... (And, yes, with a
datagram-oriented protocol, such as UDP, the situation is very
different... There, the protocol DOES know about individual
messages, and they are able to be read and handled separately...
But, TCP isn't like that, at all...)

[vonaldinjo]

Hello,

Thanks a lot for the detailed answer.
Will the flag MSG_WAITALL for recv() function help me in this case?

vonaldinjo

[RobSeace]

Yeah, on systems that support MSG_WAITALL, it should give
you another easy method of reading a fixed amount, without
needing to create your own wrapper function to keep looping
until you get it all... But, personally, I would always rather just
write my own looping cover function to do it... It should work ok,
though...

[vonaldinjo]

Hello,

Yes, waiting in a loop until receiving all worked. Though MSG_WAITALL alone did not work. Guess it is not supported.

thanks for the responses
vonald