useful note for WinSock users
Hernán Castelo
for winSock control users:
the problem was
> if sent frame A= "...data A..."
> and sent frame B= "...data B..."
> the winSock sent only 1 frame, such
{A+B}= "...data A......data B..."
this is related with TCP:
for avoid the congestion problem
caused by a great number of "tinygrams"
waiting for ACKnolwdge (response)
the RFC896 designed the Nagle algorithm
* TinyGrams are very small packets
wich size is less than TCP frame size,
that is 1460 Bytes *
Nagle algorithm merge these small packets
until the merged stream left to be "tinyGram"
(reasonable size for transmit)
The algorithm can be disabled
with setSockOpt if you use low-level functions
I'm using winSock controls
and found 2 ways to solve this matter:
1) put control characters at the end of message
thus the outgoing ( unwanted ) message will be
"...data A...\@...data B...\@"
being \@ the end-of-message character
Of course, the other side, the recipient
must scan the message looking for \@
2) simply add a pad the the message
in order to bypass the Nagle algorithm
that is, sending longer packets
( i add a pad of 2^10= 1024 Bytes )
I hope this article can be useful
because was very hard to me
to found the right way for fix the problem
(that, actually, is not a problem
but a TCP policy)
[Attached documentation from the MSDN]
Hernán Castelo
hcas...@cedi.frba.utn.edu.ar
Alun Jones
>the problem was
>
>> if sent frame A= "...data A..."
>> and sent frame B= "...data B..."
>> the winSock sent only 1 frame, such
> {A+B}= "...data A......data B..."
>
>this is related with TCP:
This is not merely "related" to TCP, nor is it a problem. It's a fundamental
part of the way TCP operates. TCP is a reliable, byte-stream,
connection-oriented protocol. As a byte-stream protocol, it _must_ not care
about whether you called send twice, once, or three thousand times, it _must_
treat it as a single stream of bytes.
>for avoid the congestion problem
>caused by a great number of "tinygrams"
>waiting for ACKnolwdge (response)
>the RFC896 designed the Nagle algorithm
The Nagle algorithm is _not_ the only way that two send() calls will appear to
be rolled into one. TCP is a byte-stream protocol, and as such _will_ pack
data together wherever it can.
>1) put control characters at the end of message
>thus the outgoing ( unwanted ) message will be
>"...data A...\@...data B...\@"
>being \@ the end-of-message character
>Of course, the other side, the recipient
>must scan the message looking for \@
Yes. Do this, or something like it. Some protocols over TCP use a delimiter
(and find some way of guaranteeing that the delimiter doesn't occur in the
body of a message), other protocols use a length count.
>2) simply add a pad the the message
>in order to bypass the Nagle algorithm
>that is, sending longer packets
>( i add a pad of 2^10= 1024 Bytes )
The Nagle algorithm (and other coalescence methods) is designed to _reduce_
wasted bandwidth. Trying to avoid the algorithm by wasting more bandwidth is
truly ridiculous.
>I hope this article can be useful
>because was very hard to me
>to found the right way for fix the problem
>(that, actually, is not a problem
>but a TCP policy)
This is a very standard TCP issue for new network programmers. It's covered
in every book that teaches you how to program TCP networking. I don't
understand how it was hard for you to find how to work with TCP.
Alun.
~~~~
[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email al...@texis.com
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.
Hernán Castelo
i'm understand
(be noticied
my friend
all is hard
here in Argentina)
best wishes