| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 14-MAR-1997 14:30:57.84
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: RE: select and socket
Hello Hu Rui
>I use select on a group of sockets, when one of the socket's peer side
>close the socket during select period, how the select will do? How can I
>identify which socket has been closed.
>
>Is the select return immediately? If it is what is the return value? How
>can I identified the closed socket?
I can't see anything in the documentation that describes what should happen
here.
I wrote a program so that I have a select() waiting to read a message from two
sockets. The effect of one of the peers closing his socket at the other end is
exactly the same as if he had sent a zero byte message.
In other words, select() terminates as soon as the close occurs, FD_ISSET
indicates which socket did the close, and a subsequent call to "recv()" returns
zero.
Does this help you? If not, perhaps you could indicate why you are asking this
question - do you have code which depends on a particular behaviour? Are you
finding that Digital Unix is behaving differently from other platforms?
Regards
Nick Hudson
Digital Software Partner Engineering
|
| From: VBORMC::"[email protected]" "Hu Rui" 14-MAR-1997 15:41:47.43
To: "[email protected] - UK Software Partner Engineering 830-4121
14-Mar-1997 1430 +0000" <[email protected]>
CC: "[email protected]"
Subj: RE: select and socket
On Fri, 14 Mar 1997, [email protected] - UK Software Partner Engineering
830-4121 14-Mar-1997 1430 +0000 wrote:
> Hello Hu Rui
>
> >I use select on a group of sockets, when one of the socket's peer side
> >close the socket during select period, how the select will do? How can I
> >identify which socket has been closed.
> >
> >Is the select return immediately? If it is what is the return value? How
> >can I identified the closed socket?
>
> I can't see anything in the documentation that describes what should happen
> here.
>
> I wrote a program so that I have a select() waiting to read a message from two
> sockets. The effect of one of the peers closing his socket at the other end is
> exactly the same as if he had sent a zero byte message.
>
> In other words, select() terminates as soon as the close occurs, FD_ISSET
> indicates which socket did the close, and a subsequent call to "recv()" returns
> zero.
>
> Does this help you? If not, perhaps you could indicate why you are asking this
> question - do you have code which depends on a particular behaviour? Are you
> finding that Digital Unix is behaving differently from other platforms?
Thank you very much, it helps in this case. But I would like to recommand
Digital to document this kind of features. It is very important for my
program. Those IPC socket read and write functions are very basic library
used by all our products. We have to make it absolutely reliable. I need
to comfirm all the possible situation.
I do not like to put alarm in this case, too many signals will hurt the
performance.
I have found serverl problems about socket in Digital UNIX that are not
documented in any where. For example.
read's return value where read from TCP socket. In case of Blacking mode,
Nonblock mode. In all the situations, when client closed the socket by
correct hand shaking, when client crash, when client has nothing to send,
when client send something and it did all arrived in one parcket, when
client send something big and it came as several parckets.......
I have the answer by testing it myself, but I need the confirmation. I
have no idea, is it the same case in different version of DEC UNIX, it
is even harder to think about porting.
We are running Digital UNIX 4.0, and 3.0.
Regards.
_________________________________________________
Hu Rui
R&D, SMS Unit (ASAP code A60205)
Scandinavian Softline Technology Oy
Tulkinkuja 3 02600 ESPOO Finland
tel. +358-9-5495 6202 fax. +358-9-512 4629
home tel. +358-9-2789426
Internet: [email protected] http://www.softline.fi/
_________________________________________________
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA23812 for
<[email protected]>; Fri, 14 Mar 1997 16:38:45 +0100
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA00164 for
<[email protected]>; Fri, 14 Mar 1997 16:43:26 +0100 (MET)
% Received: from ameeba.inet.fi (smtp.inet.fi [192.89.123.192]) by
server21.digital.fr (8.7.5/8.7) with ESMTP id QAA24366 for
<[email protected]>; Fri, 14 Mar 1997 16:46:14 +0100 (MET)
% Received: from armi.softline.fi ([194.197.150.5]) by smtp.inet.fi with SMTP id
<6536-24919>; Fri, 14 Mar 1997 17:31:17 +0200
% Received: from localhost by armi.softline.fi; (5.65/1.1.8.2/29Apr96-0950AM) id
AA20743; Fri, 14 Mar 1997 17:39:42 +020
% Date: Fri, 14 Mar 1997 17:39:41 +0200 (EET)
% From: Hu Rui <[email protected]>
% To: "[email protected] - UK Software Partner Engineering 830-4121
14-Mar-1997 1430 +0000" <[email protected]>
% Cc: "[email protected]"
% Subject: RE: select and socket
% In-Reply-To: <[email protected]>
% Message-Id: <[email protected]>
% Organization: Scandinavian Softline Technology
% Mime-Version: 1.0
% Content-Type: TEXT/PLAIN; charset=US-ASCII
|
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 17-MAR-1997 14:00:44.33
To: nm%VBORMC::"[email protected]"
CC: HUDSON
Subj: RE: select and socket
Hello Hu Rui,
Following your question, I asked the engineering group to confirm whether the
behaviour I saw was "expected". Below is a copy of my question and their
answer.
Regards
nick
--------------------------------------------------------------------------------
Note 9186.0 What happens to "select(2)" when peer closes connection? 2 replies
--------------------------------------------------------------------------------
I have a server that is talking to two clients, and is using select(2)
to wait for one of them to write a message.
Is there a way to tell that one of the clients has closed his end of the
connection?
Experimentation here suggests that when a client does a close in this
situation, then select() behaves as if that client had sent a zero byte
message - i.e. select returns as soon as the close occurs, FD_ISSET
indicates the socket which was closed, and recv() on that socket returns
zero.
Is it safe to rely on that behaviour? If so, what should the server do
to distinguish between closed sockets and zero-byte messages?
I can't see anything in the documentation which describes this situation
(but I'm ready to be pointed at the right place!)
Thanks for any input
nick
--------------------------------------------------------------------------------
> Is it safe to rely on that behaviour?
Yes. BSD style sockets behave like regular file descriptors,
a read of 0 indicates EOF.
Do note that Winsock behaves differently, at least Winsock 1.1
under Windows NT. A disconnected socket is not considered
selectable for "read". You also have to select for "except"
(at least if you are doing non-blocking connects which is when
I discovered this).
> If so, what should the server do
> to distinguish between closed sockets and zero-byte messages?
You didn't indicate which address family/protocol you are
using. If you are using TCP/IP, there is no such thing
as a "message" as TCP/IP is a STREAM abstraction, so that
also means there is no such thing as a zero-length message.
If you are talking about AF_DECnet sockets using the SOCK_SEQPACKET
data abstraction, then see the man page for dnet_eof (or the
appropriate DECnet specific getsockopt to get the connection
state).
|
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 18-MAR-1997 10:52:48.55
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: re:select and socket
Hello Hu Rui,
A final piece of information.
I wrote that my "select()" completed when a client sent a "zero byte
message", and asked the engineering group how I could determine from my server
how my server could tell the difference between this case and the one where the
client has closed the connection.
My client program was incorrect. It was doing:
send(sock,NULL,0,0);
shutdown(sock,2);
So in fact my server was seeing the result of the shutdown, not the send.
In other words, it is safe to say that when your select() terminates and you
find that a socket has sent a "zero byte message" (recv() returns zero), then
that socket connection has been closed.
Regards
Nick Hudson
Digital Software Partner Engineering
|