Ok, so perhaps it wasn't such a dumb question. Seems like many understand different facets of the whole.
My initial understanding was when I had connected to a port, I had that port tied up. Apparently, that may be wrong. I likened it to plugging a coax cable into port xx of a 3174. Mine! and no one else can have it. But now that I think of that, boy was that dumb! I can't believe I went 12 years with that concept in my head. Back in the days of the "big old box" before the IBM 3172. I seem to recall a transmission rate of about 48K. 1994 or so, that idea was planted in my head. Funny, how things last. I just spouted that crap to a co-worker Friday, when he kept getting FTP busy when he was trying to do a FTP from the VSE LST queue. So, as I rethink things... This is more of a conceptional view, not to be bogged down with facts <G>. A client puts a packet on the transmission medium, 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). It also contains the IP address and the port/socket that the results should be sent back to. 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. 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. 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). The IP stack shouldn't throw packets away, but the connecting process, just might discard packets, depending on what the application designers wanted. The process receives the message. If there is a connection number associated with the message, it identifies the long running communication (such as tn3270) that this message is for. 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. 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. Obviously, when I LPR to a printer, that someone else is sending a large printout to, I get a port busy. I've had cases when I FTP'ed to a server, of getting a "port busy" message. An immediate retry usually works. Is port and socket the same thing? How are they different? Tom Duerbusch THD Consulting (trying to update obsolete memory locations)
