yes, when I am working on the application level, most of the TCP details are taken care of. But, I want to know the underlying architecture. That is, all these application message will be broken down into packets at the TCP layer. 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? 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? What I have seen from at the application layer is that all return response will ONLY be received until all requests have been sent. regards, Cham >-----Original Message----- >From: Statux [mailto:statux@bigfoot.com] >Sent: Friday, August 04, 2000 2:45 PM >To: Cham, LP >Cc: netdev@oss.sgi.com; linux-net >Subject: RE: TCP Management > > >I think you answered most of your own question... if you're >working in the >application layer.. then most of the TCP details are already taken care >of. > >> >> The question is, will the response be sent out to the >> >> server when the server is still continuously sending >> >> the request. How is this managed and by which level - the kernel? > >The client and server don't know exactly what each other are >doing until >data is received... provided there is no corruption in the >data. Packets >are handled by TCP.. which is controlled by the kernel, but if you're >doing application level replies, etc.. then it's the >application.. which >then runs through TCP, then IP (v4 or 6), then the datalink, etc. > >> >> How long and how much can the server holds the outgoing response >> >> before he has a chance to send out the response? > >This isn't written too well. Hard to understand :) > - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
