On Fri, 2002-12-20 at 16:01, John McCartney wrote: > I'm looking for the deinitive answer on who can terminate a session in > IP/IPX/Appletalk networks.
[my apologies for the long-winded reply] Well... it depends. In the strictest sence, all of the protocols you mentioned are connectionless, so there's nothing to break. Any state added is added at the transport layer immediately above. In the case of IP, the connection-oriented general-purpose transport layer protocol is TCP. Narrowing it down to TCP/IP (because I have mostly forgotten about session-related stuff on top of appletalk and ipx and it's too late to look it up ;)... TCP is connection-oriented. Only one side can initiate a connection (duh) but either side can break it. There are several ways. Each application protocol defines the way connections are broken if they spec a connection-orient transport. Also, TCP can break its own connections. In one common scenario, the client will connect, do its thing, and initiate the disconnect. This is the way protocols such as SMTP, POP3, TELNET, SSH, and most others work. The "I'm ready to close" signal gets sent from client to server. In one notable exception to this practice, HTTP is often handled differently. The client connects to the server, and the server, after sending back the full response, initiates the disconnection. Also, in a slight warping of the terms client and server, FTP servers close data connections. Also, TCP can close its own connections by sending a RST packet to the peer. This is usually done when state gets screwed up, but it can be done for any reason, really. It is not the nice way to close a connection, though, as it implies an error condition. Also, this can't (usually) be done by a program; rather, this is done by an OS. Also, I've been imprecise up to now on the meaning of "close". TCP connection termination involves a "four-way disconnect". Each end sends a FIN packet, ack'd by the opposite end. Only when all four segments have been sent/received will both ends consider the connection to be closed. There's an intermediate state that a connection can be in called "half-closed". This is where one end has sent its FIN (and possibly had that FIN ack'd by the other side), but the other end is still sending data. Programmatically, this is accomplished by a call to shutdown(). For example, a web browser might send its full request (something like "GET / HTTP/1.0\r\n\r\n") and then call shutdown() and wait for the response. The server would then send back its data and the client would just be able to ACK, until the server finally closes its half. In a more abstract sense, a connection is just an agreement between two end systems to communicate together with some operational parameters. Connections over connectionless protocols (such as IP) require additional state to keep things straight - they have to manage flow control, data integrity, and so on. People do occasionally re-impliment the ideas behind TCP using other protocols. Several routing protocols implement their own network protocols. Real-time streams are inappropriate for TCP due to its retransmission and segmentation behaviors (among other things), but they still maintain the concept of a connection. You occasionally hear of ATM, Frame Relay, X.25, and kin referred to as connection-oriented protocols. They are, but in a much different sense. These are connection-oriented *network* protocols. Connectionless network protocols rely on communication endpoints to maintain state of connections (done with transport protocols like TCP). A packet is a packet on the network. Other than for the sake of optimization, no state exists in the network for a given pair of hosts in an IP network. This makes packet forwarding (relatively) expensive but is not sensitive to the number of hosts or the number of communicating hosts (which, if you think about it, is in the neighborhood of the square of the number of hosts on the network ( O(N^2) ), and would be hard to keep up with). The downside is the expense of figuring out the next hop for a given packet. Tons of optimizations have been made here, but they generally involve a trade-off between RAM and CPU. In the best case, you could have O(log N) lookup times (N is the number of IP addresses on the network), but it'd cost O(N) bytes of RAM. In fact, a trivial implementation would be 8 bytes per address (address and next hop, 32 bits each), leading to a 32GB memory requirement, which is not feasible in current routers. Perhaps Howard or someone else could comment on the state of the art with regard to the CPU vs. RAM compromise. In contrast, a frame relay network (for example) requires state in every switch between communicating endpoints. Specific signalling protocols have to set these connections up and tear them down, or (commonly) the connections have to be hard-coded in switches. This makes for a different problem - you have a O(N^2) scaling problem, but packet forwarding is fast (O(log N) in a binary search switching table implementation). However, sometimes it's easy to tolerate the N^2 problem, because that assumes a "dense mesh". The Internet is really a "sparse mesh" of hosts, so you don't really have N^2 connections, or even close to it. (Note the difference between a sparse physical mesh, which is obvious, and a sparse connection-based mesh, which is less obvious). There are some interesting problems that have to be addressed in connection-oriented protocols (TCP) implemented on connectionless transports (IP). Just to whet your appetite, one of my favorites is the Two Army Problem. Imagine two hills and a valley in between. Imagine two armies - army A has 100,000 soldiers and army B has 75,000. Army A is divided, 50,000 soldiers per hill. Army B is in the valley. If either half of army A attacks army B alone, army B will win. Clearly, the halves of army A must coordinate. The problem is the only way they can coordinate is by messenger, who must ride through the same valley where army B is camped. This is an unreliable transport. :-) The problem is this: how can you get the two halves of army A to agree to attack army B at the same time? The message from hill #1 to hill #2 might be dropped, so hill #1 would need to get a positive resopnse (an ACK) from #2 to be sure it won't be riding to its doom. However, the ACK is just as likely to get lost on its way back. The soldiers on hill #2 know that if that ACK doesn't get to hill #1, #1 won't attack, and #2 will ride to defeat. Now hill #2 decides it needs an ACK to its ACK. This is an unsolvable problem. It's relavence to TCP has to do with the way TCP breaks connections. How does one end know that it should shut down a connection, stop accepting packets, return to the calling program, etc? How can it be sure that the other side understands that the connection is broken too? There are serious implications from a security standpoint in connections that linger open after the other side thinks they're closed, and serious application state problems for connections that close too soon. The compromise the designers of TCP reached was the four-way disconnect. Enough of the technical stuff - more info is in the TCP RFC: http://www.ietf.org/rfc/rfc793.txt Also, I recommend reading the relavent section of Tannenbaum's _Computer Networking_ - there is a good discussion of the theoretical underpinnings of connection state maintenance. Enough of my rambling. -sd Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=59674&t=59656 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
