Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Socket Problem

2 views
Skip to first unread message

Tony Roby

unread,
Sep 15, 1992, 1:00:50 PM9/15/92
to

Does anyone have any clues as to why we experience the following problem
using sockets on AIX 3.2.1 ?

We send a message, consisting of a header and data in two parts onto a
socket. The receiver receives the message in two parts. The header
is always 64 bytes long. When the data portion is 1451 bytes long (or less)
the response time is more than when the data portion is 1452 bytes long; 'more'
means consistently longer by about .2 of a second. The same thing happens
for data portions 1453-2903 bytes long, but data portions 2904 bytes and
longer have good response times. We are running over Token Ring and the
maximum IP packet size for TCP/IP is 1492 bytes (is this a clue ?).

When we combine the header and the data in one message, response times are
consistent over all message sizes.

Any ideas would be welcome.

Tony

Tom Truscott

unread,
Sep 16, 1992, 8:02:27 PM9/16/92
to
>... When the data portion is 1451 bytes long (or less)

>the response time is more than when the data portion is 1452 bytes long; 'more'
>means consistently longer by about .2 of a second.

I suspect you have bumped into Nagle's small packet avoidance algorithm
for TCP (RFC896), which delays small data until any previously
transmitted small data has been ACKed.
The receiving system has a .2 second delay before ACKing a received packet
in hopes that the ACK can be piggybacked on a response.

To avoid this problem, I recommend you send both header and data
with a single call. You can use "gather" I/O supported by writev()
or sendmsg(). For a small efficiency gain you can also read head and data
with a single call such as readv() or recvmsg().

The easiest hack fix, though, is to call:
int yes = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &yes, sizeof(yes));
which causes data to be send immediately.

0 new messages