Steve Dispensa wrote: > > 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]
Great answer. I wrote a long one too, but Group Study swallowed it. I think it crashed right when I sent my message. ;-) And there's a lesson in that. One good reason that either side can terminate a session is that either side could crash! You covered the TCP/IP world, but I just wanted to add that in the AppleTalk world we have: AppleTalk Transaction Protocol (ATP) AppleTalk DataStream Protocol (ADSP) AppleTalk Session Protocol (ASP) Either side can terminate sessions with those protocols, although which side does depends on the application, which could be Apple Filing Protocol (AFP), Printer Access Protocol (PAP), Name Binding Protocol (NBP), or Zone Information Protocol (ZIP). I'm afriad I can't remember which side usually terminates for each of those, but theoretically either side could. In the Novell world, sessions happen in the NetWare Core Protocol (NCP) and NetBIOS over IPX (NWLink) protocols. I think either side can terminate a session in those cases too. Terminating sessions happens for many reasons, which is why most protocols let either side terminate. Some reasons that come to mind: The client has gotten all the data it wants. The server has come to the end of the data it wants to send. The user quits the application. The user goes out to lunch. The server goes out to lunch! ;-) An intrusion detection system notices something weird. Priscilla Priscilla > > 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=59734&t=59656 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
