On 2001.12.19, Jerry Asher <[EMAIL PROTECTED]> wrote: > When someone clicks on a bring-your-server-to-the-knees-query, [...]
I think Pete's point is (Pete, correct me if I'm wrong): What goddamned business does any web developer have desigining a single page that fires off a bring-your-server-to-its-knees type of query or functionality? "Doctor, doctor, it hurts when I code things poorly!" > Is it possible for a TCP based connection to know when a socket is > broken *as it happens*? Depends. If the remote end tears down the socket connection, it will send a FIN. The server sees the FIN and knows that the remote end wants to tear down the connection, so it sends back an ACK, then its own FIN (when it starts to tear down the connection, via close() or whatever). Then it expects an ACK from the remote end. This is typically what happens when a user hits "stop" in their browser. If the remote end "disappears" off the network, no FIN will arrive. In this case, the only way to know if the remote end is still listening is to send it a datagram and wait for the ACK ... and if you get no ACK, then the connection is dead. This typically happens when people are connected via dialup, and their modem hangs up. > If possible is that an efficient manner to run webserver based > communications? If it was, don't you think that's the way most webservers would be implemented? AOLserver could probably get away with it if the thread handling the socket connection was seperate from the thread executing the code generating the page to return ... but is it really worth it, if you design your web applications properly? -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
