Very Computer

by **Ramesh** » Thu, 02 Aug 2001 00:14:20

We find that, when a client has already closed the socket and server tries
to write some data to that socket using select() & write() systems calls,
they succeeds. Has any body faced similar problem?

Is there any TCP driver paramteres which we can configure so that the
select()/write() calls detects the stale socket handle and retruns error?

Thanks,
Ramesh

by **Ramesh** » Thu, 02 Aug 2001 06:47:52

It is running on Solaris 2.7

> # We find that, when a client has already closed the socket and server
tries
> # to write some data to that socket using select() & write() systems
calls,
> # they succeeds. Has any body faced similar problem?
> #
> # Is there any TCP driver paramteres which we can configure so that the
> # select()/write() calls detects the stale socket handle and retruns
error?

> Is this running under any particular OS?

by **Ramesh** » Fri, 03 Aug 2001 00:51:23

> # It is running on Solaris 2.7
> #

> # > # We find that, when a client has already closed the socket and
server
> # tries
> # > # to write some data to that socket using select() & write()
systems
> # calls,
> # > # they succeeds. Has any body faced similar problem?
> # > #
> # > # Is there any TCP driver paramteres which we can configure so that
the
> # > # select()/write() calls detects the stale socket handle and
retruns
> # error?
> # >
> # > Is this running under any particular OS?

> Please don't put the text of your reply prior to the post.

> ----

> I ran into this recently at a brokerage firm.

> The "client" was a PeeCee, and its close() was
> stuck in either FINWAIT1 or 2.

> You'll have to program around it.

> Detect hung sessions with a heartbeat or a timeout.

> Does netstat show FINWAIT for these hung connections?

I see the client socket on FIN_WAIT_2 for a minute or so and then is goes
away. It's a bit trickey to code around it. The application we are working
on is a middleware/workflow engine.

We receive the transactions over socket from an external system (which we
don't own). Some of the tasks require that we communicate to some network
devices and reply back to the external system on that socket with-in a
predefined time interval, if not the external system times-out and closes
the socket (thinking something is wrong). In normal situations things are
good. But when one of the network element is down or slow we get into this
problem. So when we try to send the reply back at a later time, we would
like to detect that the socket has been closed by the external systems so
that we can log and generate an alarm, for later reconciliation of the
transaction.

by **Rick Jone** » Fri, 03 Aug 2001 06:44:54

> We find that, when a client has already closed the socket and server
> tries to write some data to that socket using select() & write()
> systems calls, they succeeds. Has any body faced similar problem?
> Is there any TCP driver paramteres which we can configure so that
> the select()/write() calls detects the stale socket handle and
> retruns error?

Select for both read and write on the socket, check read first. If the
return from read is zero, it means the remote has called either
shutdown or close - you have just received the TCP FIN segment. You
have to know more about the client to know if it simply calls close(),
in which case it will neither send, nor recv any more data, or if it
called shutdown(), in which case it may have simply stated it will no
longer send data but will still recv it.

HOWEVER...

There will always be a window. Your app could select on the socket,
and come-out of select and enter write just before the client closed
his end of the connection.

--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain...

Very Computer

select()/write() does not generate error on a closed socket

select()/write() does not generate error on a closed socket

select()/write() does not generate error on a closed socket

select()/write() does not generate error on a closed socket

select()/write() does not generate error on a closed socket