TCP replated question.

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
vividhAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

procguyCommented:
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
vividhAuthor Commented:
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
vividhAuthor Commented:
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
Exploring SQL Server 2016: Fundamentals

Learn the fundamentals of Microsoft SQL Server, a relational database management system that stores and retrieves data when requested by other software applications.

vividhAuthor Commented:
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
vividhAuthor Commented:
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
procguyCommented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.