Re: Question: Designing a protocol over TCP

From: Stanley Feng \(MSFT\) (sfeng_at_microsoft.com)
Date: 02/18/04 

Date: Wed, 18 Feb 2004 14:28:42 -0800

CK -

Actually you raised a very interesting question, i.e., when does winsock/TCP
complete your receive() call?

Your receive() call will be completed as soon as an incoming TCP segment has
the push bit set, or the receive buffer has been completely filled, or there
is expedidated (urgent) data in the TCP stream and the socket has been set
as OOB_INLINE, or various other conditions where the windows networking
stack determines that your TCP recv() call should be completed.

Once your recv() call has been completed, you will be given "BytesReceived"
of this recv() operation. Chances are, this "BytesReceived" will be equal to
the number of bytes sent by ONE send() operation from the sender's side, or
chances are, this "BytesReceived" will be equal to number of bytes sent by
MULTIPLE send() operations from the sender's side, or changes are, this
"BytesReceived" will be _less_ than the number of bytes sent by ONE send()
operations from the sender's side. Possibility is endless.

Very likely, in the example code you've seen so far, the I/O patten on the
sender and receiver side makes it possible for the receiver side to always
complete recv() calls with exactly the number of bytes the sender has sent.
(Imagine this: Receiver posts 200 bytes of receives, sender sends 100 bytes,
sender stops, do nothing. Reciever will see that the recv() be completed
with 100 bytes.) 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples (if any) are subject to the terms specified
at http://www.microsoft.com/info/cpyright.htm"
"C K" <blah@blah.com> wrote in message
news:btndh7$khd$1@newstree.wise.edt.ericsson.se...
> Ok, that's the answer that I was looking for.  Basically that there SHOULD
> be code that "rebuilds" the byte stream back into a valid message, checks
> for boundaries, etc...
>
> Thanks for the responses everyone.
>
>
> "David Schwartz" <davids@webmaster.com> wrote in message
> news:btnc3i$n2o$1@nntp.webmaster.com...
> >
> > "C K" <blah@blah.com> wrote in message
> > news:btmrv0$dcp$1@newstree.wise.edt.ericsson.se...
> >
> >
> > > What I was trying to get at was that maybe there was something
different
> > > with the way Windows handles the receives based on the different modes
> > > that
> > > would cause such behavior.  I was trying to figure out why this
example
> I
> > > was looking at always received one full message regardless of the
> message
> > > sizes that I tried.  There was no code that was "rebuilding" the
message
> > > from the byte stream.  It just received it all at once when the GQCS
> call
> > > returned.
> >
> >
> >     This is very typical of TCP. This is why there are a lot of programs
> out
> > there that assume this will always happen and break the first time they
> > encounter an unusual situation.
> >
> >     DS
> >
> >
> >
> >
>
>

Relevant Pages

  • Re: sending images over a socket
    ... > A recv() call only returns the data received up to that point. ... > in the sockets implementation, ... > the receiver must fetch this length first, ... > - The sender and receiver always know exactly how much data is transferred ...
    (comp.unix.programmer)
  • Re: How to Quicken TCP Re-transmission?
    ... Actually, TCP is a single sliding window protocol, which limits its ... If the receiver can notify ... position than the sender to judge when a packet is actually lost. ...
    (freebsd-net)
  • Re: Controlling rate of tcp/ip data transmission
    ... the receiver has 0 TX and the sender has 0 RX on the connection. ... TCP was developed precisely to solve problems just like ... to the sender you cannot use TCP, and some sort of rate-based pacing ...
    (comp.os.linux.networking)
  • Re: sending images over a socket
    ... A recv() call only returns the data received up to that point. ... It may close it's sending socket when it has sent all the data; the receiver ... The sender and receiver always know exactly how much data is transferred as ... that fixed amount is; both sender and receiver must agree on what this amount ...
    (comp.unix.programmer)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... The smaller the packets are, ... This is due to the fact that TCP ... > What I observe is that once the receiver is not ... > keeping up with the speed the sender is spewing packets, ...
    (comp.lang.perl.misc)