--- Tom Duerbusch <[EMAIL PROTECTED]> wrote: > Ok, so perhaps it wasn't such a dumb question. > Seems like many > understand different facets of the whole.
The only dumb question is one you don't ask. > A client puts a packet on the transmission medium, "Conceptually" a client passes the data to the TCP (or UDP) layer. The TCP layer passes the data to the IP layer. The IP layer uses the routing table to decide which interface to send the packet on... > it contains the IP > address and port/socket that the packet should be > routed to. It may > also have a connection number to distinguish > multiple long connectsions > (tn3270). The client (usually) only quotes the connection number (socket handle) and the data to be sent. > It also contains the IP address and the > port/socket that the > results should be sent back to. This information is added by the TCP and IP layers. > The server IP stack > looks for packets > with its IP address, takes the packet/socket > (building the complete > message if multiple packets were used), and > transfers the data to who > ever is listening on the specified port/socket. > Again its an IP "stack" so the IP layer has a protocol byte which says to pass either to the UDP or TCP layer. If its TCP the TCP layer will handle re-transmission, missing packets etc. It uses the from/to address/socket number pairs to work out which socket (connection number) to pass the data up to. > So, any process is only going to get one message at > a time. It is up > to the process to be able to handle or buffer many > messages. TCP will do some of this for you. > If it > can't, it should post a flag (busy bit) back to the > IP stack. If the > "busy bit" is set, the IP stack either sends back a > NAK or something > back to the client (perhaps the busy condition). If you are using TCP not reading the data will cause the TCP/IP stack to apply back pressure to stop the other end from sending. You don't need to set busy bits. See the MAN pages for SEND, RECV and POLL/SELECT. > The IP stack shouldn't > throw packets away, but the connecting process, just > might discard > packets, depending on what the application designers > wanted. Nope. The IP layer is at liberty to throw away whatever it wants or to send the packets to whatever node it wants to. The TCP layer (assuming you are using TCP) has to sort out the mess the IP layer makes and get the data packets in the right order (because some might be sent in different directions the might arrive out of order) and get missing data re-transmitted (because the IP layer threw it away). The application then reads then as it needs. If data arrives too quickly again TCP has to apply back presure and buffer. > > The process receives the message. If its TCP the process see a byte stream. If it wants to divide it into messages it can. > If there is a > connection number > associated with the message, it identifies the long > running > communication (such as tn3270) that this message is > for. > TCP uses special messages to set up the call. > If the process is a short running process (tn3270), > it handles it and > returns a message back to the IP stack. If the > process requires a lot > of resources (FTP), the message is routed to another > task for async > processing and immediately returns a message back to > the IP stack. > Nope. There is no fixed association between processes and connections. A single process (typically HTTP) can handle many calls, or you can start a new process per call. On UNIX systems there is a process call INET that listens for connections and spawns tasks. However its fully configurable. > But if ports can be shared, how do I get "port busy" > for a FTP to VSE? > Now I see that, by default, I specified two FTP > daemons. I assume that > I can do two FTP transfers at the same time. Sounds > logical. Because TCP knows nothing about starting applications when a connection arrives. When a TCP connect primitive arrives, if no application is listening, you will get a "port busy" or similar. > > Obviously, when I LPR to a printer, that someone > else is sending a > large printout to, I get a port busy. > You might. Some printers buffer multiple prints. Other might accept the connection and then not read any data... > I've had cases when I FTP'ed to a server, of getting > a "port busy" > message. An immediate retry usually works. > Usually FTP servers are limited to say "n" downloads. "busy" means the limit is reached. If they are small files there is a good chance a transfer will work. > Is port and socket the same thing? How are they > different? > A "port" is a data field within the protocol. Port numbers for well known processes are assigned by ICANN. A socket is somewhat akin to a DD name or Fortran I/o number. Its a handle which refers to a particular connection. http://www.die.net/doc/linux/man/man7/socket.7.html might help. > Tom Duerbusch > THD Consulting > (trying to update obsolete memory locations) > Hope the above helps... Dave. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
