> yes, when I am working on the application level, > most of the TCP details are taken care of. Right. > But, I want to know the underlying architecture. > That is, all these application message will be broken > down into packets at the TCP layer. Right. > And, are there two separate buffers at that layer to handle > incoming and outgoing packets? If the server continuously > send packets to the client, does the client has a chance > to send back the processed packet? There are two buffers: one for sending and one for receiving. > If not, outgoing packets must be kept in the buffer > till he has a chance to be sent out. But, there must be > limit as to how much the buffer can hold. Is this > implementation at the kernel layer and does it varies > between OS? There are limitations to every buffer. Different kernel implementations and different operating systems are roughly the same thing, unless something's been tweaked, etc. The TCP/IP defaults are defined by the implementation and do often vary from OS to OS... but these defaults can usually be changed at runtime using different functions. High and Low water marks for sending and receiving are changable. A book or some other TCP/IP info resource is helpful. I have my UNIX Network Programming book from W. Richard Stevens :) Very good book. > What I have seen from at the application layer is that > all return response will ONLY be received until all > requests have been sent. It depends on how it's implemented. If you're doing batch work.. like send everything.. then receive everything.. then you'll be stuck with what you're describing, for example. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
