On Wednesday, 05/17/2006 at 12:23 EST, Tom Duerbusch
<[EMAIL PROTECTED]> wrote:
> 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.
Almost, but not quite. To make programming easy, the sockets programming
paradigm has a concept called "bind". This means that the program socket
is glued to a {local_ip, local_port, tcp} tuple. When it connects to
another program at {remote_ip, remote_port, [same] protocol} or is connect
to by said program, the two tuples are merged into a "connection" or
"session" which is expressed in a tuple of the form {local_ip, local_port,
remote_ip, remote_port, protocol}. Each program has its own socket.
Socket numbers are unique with an address space, but on a system with
multiple address spaces, there is no nice way to uniquely identify a
particular socket. Enter the "connection number". It is essentially a
1-n list of all connection tuples.
So, the "connection number" is not part of the packet. It is a purely
local construct that allows us mere humans to reference a connection tuple
more easily.
Oh, and only when the protocol is TCP will duplicate packets be discarded
and missing packets be re-requested before giving the message to the
application.
> 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.
If you really want to know how pacing is handled by TCP using "windows", I
suggest going to the library or bookstore and getting a TCP/IP protocol
book. Programmers typically get themselves into a bind (bind?!? Get it?
Bind? ha ha ha ha! I love TCP/IP humor!) when they forget that TCP is a
stream protocol, not a message protocol. That is, the sender may send
1000 bytes, but the receiver may not get all 1000 at a time. This is why
application protocols are replete with "length of message" fields and
delimiters.
IP *will* throw packets away if TCP or UDP won't accept them (inbound) or
if IP doesn't know what to do with them (outbound). This where the
Protocol Wars began: IP is an unreliable mechanism for delivery of
messages. UDP is the protocol that a program can use to mimic this
unreliable behavior. TCP, on the other hand, is just as reliable as SNA.
> 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.
No, that's what the port number is used for. If you have multiple TN3270
windows open, each one has a different local port on your PC
{same_local_ip, unique_local_port, remote_ip, 23, TCP}. Since each
local_port would be unique, that represents two sockets.
> 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?
"port busy" is what you get when a socket tries to specify the same
local_port as another application on the same host. We see this with LPR
because the ancient RFC for LPR required the *client* to use a specific
range of ports. So it would try to bind to port 721 and find it in use.
Then 722. Then 723, and so on. When all ports had been tried, the
application would throw its hands up and say "port busy". (This is why we
say to specify SECURE=NO on an RSCS LPR link.)
Also, once a particular local_port is no longer bound to a socket (i.e. a
close() was issued), then there is a mandatory wait time (2 minutes)
before the stack will allow that socket to be reused. This is done for
safety, ensuring that any old traffic still moving [slowly] through the
network will not inadvertantly be sent to the application that just
started listing on the port. There is some programming sleight of hand to
get around this.
Whew! You don't ask easy questions! But, really, the Stevens or Comer
TCP/IP books ("TCP/IP Illustrated" or "Internetworking with TCP/IP")
provide some of the best education in existence on the details of how TCP,
UDP, IP, ICMP (ping), etc. all work. You *could* read the RFCs, but these
authors already did that and present it in a much more understandable way.
Alan Altmark
z/VM Development
IBM Endicott
