On Fri, Apr 9, 2010 at 5:52 PM, Jonathan Franklin
<franklin.jonathan@gmail.com> wrote:
2010/4/7 Matheus Araújo Aguiar <matheus.pit@gmail.com>:
> While testing the application I was having some errors related to reading a
> prefix that would indicate a strange number of bytes incoming, a number that
> was far greater than the max size possible of message in my protocol.
It sounds like you have made the problem go away.
Apparently, yes!
FWIW, on the send side of a TCP connection, you may do 4 individual
writes of 64 bytes each, but on the receive side you may only see 256
bytes of data available on the socket.
TCP is a stream protocol, so
at the application level, there is no inherent concept of packets or
messages. TCP *uses* segments, which are packets on "the wire", but
gives you a stream at the application level when you read data from
the socket. So there is no correlation between the number of writes
on the send side, and the number of reads on the receive side. It
only guarantees that you will receive the bytes in the same order they
were sent... If you receive them at all. ;-)
You must design you socket reader with this in mind. Good luck! :-)
Thanks for the tip. Actually i was already thinking like that. When i refer to messages in my post, i want to mean "number of bytes expected before reading another size of bytes expected" ..
Jon