On Jan 6, 2006, at 11:35 AM, Bhaskar, KS wrote:
Greg --
I am not sure I understand the problem.
Actually, I thought I was discussing possible scenarios, not to
trying to describe a specific problem.
If the client does not shut
down "cleanly" there are two cases to consider:
(a) The server's TCP connection goes away. This will cause the server
process to shut down cleanly.
How? is it closed? reset? or does it just time out? But in any case,
the socket doesn't go away immediately. The specification says it
needs to remain for 2 times the maximum lifetime of a packet. If you
probe with netstat, you need to pay attention to the connection
state, too.
(b) The server's side of the TCP connection somehow remains and
doesn't
go away.
Actually, if the client simply closes the socket, this will not
disturb the server. It's an example of normal behavior known as a
"half open" connection.
In this case, with a dead client the server process remains,
occupying a slot in the process table, and few square millibleems on
disk to where its memory gets paged, where it stays until the computer
gets shut down or it gets purged.
What happens depends on the protocol and the server state. A problem
can occur if the server has data to send but there is no client to
acknowledge it (at the TCP level). this triggers a series of retries
with a shrinking window. The problem is that a lot of things could be
happening here: Is it just a latency problem? Are packets being
dropped intermittently? Are they too large? Are acknowledgments being
sent but lost? Usually, you don't have to worry about these things,
but since TCP is designed to be reliable, an abrupt failure can
trigger a lot of unnecessary work at the level of the TCP stack.
So, implementing via [x]inetd and TCP would seem to be just fine.
First of all, I recommend using inetd or xinetd (and, to tell you the
truth, I'm more familiar with inetd). It was certainly not my
intention to suggest otherwise. Second, i did not mean to suggest
that TCP would not work, only that it made more sense to implement
RPCs in a LAN environment using UDP. I also meant to call attention
to the actual sequence of events as an aid in troubleshooting, not to
suggest that the existing implementation was incorrect.
-- Bhaskar
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Good acts are like good poems. One may easily get their drift, but
they are not rationally understood."
--Albert Einstein
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
