Solved

TCP replated question.

Posted on 1998-11-30
6
398 Views
Last Modified: 2010-04-21
I had a question about how are the various data lengths used in the TCP/Ip
protocol. We have the TCP_MAXSEG. This is the maximum segment that TCP can
hold. Then we have SO_RCVBUF and SO_SNDBUF to set the receive and send
buffers. Again going down the stack IP has a fixed size header and data body.
So even if I fix up the receive/send buffers how is it gaining on speed for
the transfer as later it is finally going in fixed chunks? Can some guru
illustrate how all these different buffers are organised in TCP/IP?

Please send me a mail at vividh@hotmail.com

Thanks in advance.
Vividh
0
Comment
Question by:vividh
  • 4
  • 2
6 Comments
 

Accepted Solution

by:
procguy earned 200 total points
ID: 2008162
I'll start off with the TCP_MAXSEG parameter.  IP packets are not of fixed length, and vary from packet to packet, up to a maximum of 68 octets for IPv4.  However, depending on the network interface you are using (Ethernet, Token Ring, FDDI), the network interface will have a MTU (maximum transmission unit).  For example, the MTU of Ethernet is 1500.

When a TCP/IP seesion is initialzed, the listener and initiator negotiate a maximum segment size to be used. (MSS).  The MSS is usually smaller than the MTU, if it is larger, TCP will segment it for you, but at a processor penalty since it sits higher on the stack, and uses more processor time to segment the packets.
So by tuning TCP_MAXSEG you can limit the time spent in MSS negtioations.  If your TCP_MAXSEG is too small (a normal default is 576 bytes, a value that all routers are assumed to be able to handle), the stack it spending CPU time generating too many small packets when it could be sending fewer larger ones.

The reason you would adjust the send and receive buffers is to tune the server/workstation for the type of traffic it is receiving as well as the type of interface you're working with.
For example, if a server receieves a lot of network traffic and is busy, (CPU => 80%) if the buffer space (mbufs too) that are allocated to handle network traffic are too small, the sever will drop the packets, thus having the client perform a re-transmit.  This adds load to the network, and even more load to the server (assuming TCP packets, and not UDP) since the server will have to wait for the dropped packet and properly sequence it before it can finish the orignal request (say serving a web page).

On the other hand, if the server is used as a distribution type server (ftp, etc) where it is sending large quantities of inofrmation to a few clients, then the number of send buffers needs to be increased for maximum performance, since the application will want to send the data to these multiple streams as fast as possible, or contention will occur between the application trying to send out data, and the memory pool allocated for packets.

Remember also that some hardware (NICs) have their own send and receive buffers that are completely independent of the software buffers.  How your NIC talks to your server will largely depend on its driver.  Some drivers allow raw I/O to the mbuf area and all control of buffering is done by the NIC via the driver.


Hope this helps.
0
 

Author Comment

by:vividh
ID: 2008163
What if I want to develop a server similar to ftp which basically transfers files. The number of clients accessing it are also higher. Should the send buffer in server and receive buffer in client be increased? On my system the value is some thing like 27000 for send/receive buffers? Should I increase it to 32767 or something higher.

Thanks.
0
 

Author Comment

by:vividh
ID: 2008164
What if I want to develop a server similar to ftp which basically transfers files. The number of clients accessing it are also higher. Should the send buffer in server and receive buffer in client be increased? On my system the value is some thing like 27000 for send/receive buffers? Should I increase it to 32767 or something higher.

Thanks.
Vividh
0
Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

 

Author Comment

by:vividh
ID: 2008165
What if I want to develop a server similar to ftp which basically transfers files. The number of clients accessing it are also higher. Should the send buffer in server and receive buffer in client be increased? On my system the value is some thing like 27000 for send/receive buffers? Should I increase it to 32767 or something higher.
Incase of TCP, we donot have to worry about the dropped packet right? TCP handles it. But in UDP u have to worry about the sequencing of the packets if I am not mistaken.

Thanks.
Vividh
0
 

Author Comment

by:vividh
ID: 2008166
What if I want to develop a server similar to ftp which basically transfers files. The number of clients accessing it are also higher. Should the send buffer in server and receive buffer in client be increased? On my system the value is some thing like 27000 for send/receive buffers? Should I increase it to 32767 or something higher.
Incase of TCP, we donot have to worry about the dropped packet right? TCP handles it. But in UDP u have to worry about the sequencing of the packets if I am not mistaken.

Thanks.
Vividh
0
 

Expert Comment

by:procguy
ID: 2008167
Vividh,
If you're going to run something similar to an ftp server, and you have the memory (remember adding buffer memory takes away from memory usable by programs & daemons) then by all means increase the send buffer.  32767 is a fairly larger buffer space.  I would try it first and see how performance is on the client end.  If you get too many timeouts, or it takes too long for clients to connect to the server (assuming the netowork traffic is not causing it, or the CPU[s] are not too busy), then I would increase it in steps of 8096.
You are correct about TCP and dropped packets, since TCP sequences packets, if one is dropped, it will be resent.  UDP does not care.  It is a best try protocol.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

Hello fellow BSD lovers, I've created a patch process for patching openjdk6 for BSD (FreeBSD specifically), although I tried to keep all BSD versions in mind when creating my patch. Welcome to OpenJDK6 on BSD First let me start with a little …
Installing FreeBSD… FreeBSD is a darling of an operating system. The stability and usability make it a clear choice for servers and desktops (for the cunning). Savvy?  The Ports collection makes available every popular FOSS application and packag…
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
This video shows how to set up a shell script to accept a positional parameter when called, pass that to a SQL script, accept the output from the statement back and then manipulate it in the Shell.

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now