From digilab!digilab.bio-rad.com!dmw@uu6.psi.com Wed Nov 10 06:04:30 1993 Received: from uu6.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA21608; Wed, 10 Nov 1993 11:29:10 -0500 Received: from digilab.UUCP by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA04062 for ; Wed, 10 Nov 93 11:13:23 -0500 Received: by digilab.bio-rad.com (UUPC/extended 1.12e); Wed, 10 Nov 1993 11:03:55 -0500 X-Mailer: Cinetic Mail Manager V2.1 Date: Wed, 10 Nov 1993 11:04:30 EST Reply-To: dmw@bio-rad.com From: dmw@digilab.bio-rad.com (David Watt) Message-Id: <2ce110eb.digilab@digilab.bio-rad.com> To: winsock-hackers@sunsite.unc.edu Subject: Timeouts on WSAAsyncSelect FD_READ msg -- how? Hi. I have a Winsock application in which I'd like to do an asynchronous read, but I'd like the read to time out if there's a problem, and I'd also like to do this using WSAAsyncSelect( FD_READ ) instead of using the select() function. Is there any way to configure a socket to time out directly, or should I just create a timer myself, and change the WSAAsyncSelect() flags when I receive the subsequent WM_TIMER message? (It seems like setting a socket's receive and send timeout times ought to be in the next spec -- it's explicitly disallowed in the setsockopt() discussion in the current spec.) Thanks for any help, - Dave -- David Watt dmw@bio-rad.com Bio-Rad Laboratories (617) 349-5531 [A computer is] like an old testament god, with lots of rules and no mercy. - Joseph Campbell From digilab!digilab.bio-rad.com!dmw@uu6.psi.com Wed Nov 10 11:54:19 1993 Received: from uu6.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA04127; Wed, 10 Nov 1993 17:31:39 -0500 Received: from digilab.UUCP by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA03339 for ; Wed, 10 Nov 93 17:00:41 -0500 Received: by digilab.bio-rad.com (UUPC/extended 1.12e); Wed, 10 Nov 1993 16:54:19 -0500 X-Mailer: Cinetic Mail Manager V2.1 Date: Wed, 10 Nov 1993 16:54:19 EST Reply-To: dmw@bio-rad.com From: dmw@digilab.bio-rad.com (David Watt) Message-Id: <2ce1630c.digilab@digilab.bio-rad.com> To: winsock-hackers@sunsite.unc.edu Subject: Re: Timeouts on WSAAsyncSelect FD_READ >BTW, you might want to select on FD_READ and FD_CLOSE; when you get an >FD_CLOSE, be sure to read until it no longer makes sense to do so. True for TCP sockets. Not so for UDP, though, which (I neglected to mention) I was trying to do here -- no FD_CLOSE's get posted. By the way, I have a question about setting FD_CONNECT on UDP sockets. Now granted, UDP sockets don't make connections. But if you set FD_CONNECT, and then use the connect() call on a UDP socket to set the destination address for subsequent send() calls, shouldn't the socket window receive an FD_CONNECT message? The specification is, to my mind, ambiguous on the subject: in the description of the connect() function, it says: "2. If your application is using the message-based WSAAsyncSelect() to indicate interest in connection events, then your application will receive an FD_CONNECT message when the connect operation is complete." (If I were feeling overly lawyerly, then I would suggest that if the word "connect" on the third line above were written as "connect()", then the answer to this question would be obvious. :) How does this apply to UDP sockets? In the NT implementation, which is the only one I've tested this on, UDP sockets never receive FD_CONNECT messages, which is a mild annoyance when trying to implement a protocol simulateously in TCP and UDP. >Dave > >------------------------------------------------------- >David L. Brooks >Idaho National Engineering Lab. INTERNET: dob@INEL.GOV >POB 1625 Phone: (208) 526-0826 >Idaho Falls, Id. 83415-3730 FAX: (208) 526-9908 >------------------------------------------------------- - Dave -- David Watt dmw@bio-rad.com Bio-Rad Laboratories (617) 349-5531 [A computer is] like an old testament god, with lots of rules and no mercy. - Joseph Campbell From rcq@ftp.com Wed Nov 10 15:29:27 1993 Received: from ftp.com (babyoil.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA22684; Wed, 10 Nov 1993 21:12:38 -0500 Received: from rcq.oysters.ftp.com by ftp.com via PCMAIL with DMSP id AA04419; Wed, 10 Nov 93 20:29:27 -0500 Date: Wed, 10 Nov 93 20:29:27 -0500 Message-Id: <9311110129.AA04419@ftp.com> To: dob@tis.inet.gov, dmw@digilab.bio-rad.com Subject: recv() after FD_CLOSE From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@ftp.com Repository: babyoil.ftp.com Originating-Client: oysters.ftp.com > >BTW, you might want to select on FD_READ and FD_CLOSE; when you get an > >FD_CLOSE, be sure to read until it no longer makes sense to do so. Since FD_CLOSE is posted when a connection is closed gracefully or ungracefully (i.e. when TCP or is received). And since a host cannot possibly send data after sending a TCP or . It doesn't ever make sense to read after getting an FD_CLOSE. Why should you? Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Wed Nov 17 03:56:01 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA29737; Tue, 16 Nov 1993 16:49:13 -0500 Received: by usage.csd.unsw.OZ.AU id AA13614 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 17 Nov 1993 08:47:02 +1100 Received: by atlas (4.1/1.35) id AA06368; Wed, 17 Nov 93 08:56:02 EST Message-Id: <9311162156.AA06368@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 17 Nov 1993 08:56:01 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: dmw@digilab.bio-rad.com, Multiple recipients of list Subject: Re: Timeouts on WSAAsyncSelect FD_READ Thus expounded David Watt on Nov 10, 7:35pm: /-------------------- |By the way, I have a question about setting FD_CONNECT on UDP sockets. |Now granted, UDP sockets don't make connections. But if you set |FD_CONNECT, and then use the connect() call on a UDP socket to set |the destination address for subsequent send() calls, shouldn't the |socket window receive an FD_CONNECT message? The specification is, |to my mind, ambiguous on the subject: in the description of the |connect() function, it says: | |"2. If your application is using the message-based WSAAsyncSelect() to indicate interest in connection events, then your application will receive an FD_CONNECT message when the connect operation is complete." | |How does this apply to UDP sockets? In the NT implementation, which is |the only one I've tested this on, UDP sockets never receive FD_CONNECT |messages, which is a mild annoyance when trying to implement a protocol |simulateously in TCP and UDP. This is actually a thorny problem. I was going to reply "of course a connect() on a UDP socket should have a FD_CONNECT message sent"... but ... For TCP sockets, calling WSAAsyncSelect() puts the socket in non-blocking mode automaticaly. Since connect() for TCP sockets could take arbitrary time, it then returns SOCKET ERROR / WSAEWOULDBLOCK, and you get the FD_CONNECT message some time later. For UDP sockets, though, connect() is never a blocking call - it proceedsimmediately, and will not return a WSAEWOULDBLOCK error. I guess they have implemented it so that you only get an asynchronous message (FD_CONNECT) if the related connect() attempt failed with WSAEWOULDBLOCK. An interesting experiment would be to try to connect() to a local socket on the same machine - say through address 127.0.0.1. using TCP. and seeing if that returns a WSAEWOULDBLCOK error (although I guess there's no reason why not) and if not, whether you still get a FD_CONNECT message. Check if your UDP connect is returning SOCKET_ERROR/WSAEWOULDBLOCK. If so, you definitely should get an FD_CONNECT message soon after. If the UDP connect() succeeds, there is no need to post a FD_CONNECT message - you already know its connected. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Wed Nov 17 04:00:09 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA29835; Tue, 16 Nov 1993 16:50:19 -0500 Received: by usage.csd.unsw.OZ.AU id AA13723 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 17 Nov 1993 08:50:15 +1100 Received: by atlas (4.1/1.35) id AA06438; Wed, 17 Nov 93 09:00:10 EST Message-Id: <9311162200.AA06438@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 17 Nov 1993 09:00:09 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: recv() after FD_CLOSE Thus expounded Bob Quinn on Nov 10,11:29pm: /-------------------- |> >BTW, you might want to select on FD_READ and FD_CLOSE; when you get an |> >FD_CLOSE, be sure to read until it no longer makes sense to do so. | |Since FD_CLOSE is posted when a connection is closed gracefully |or ungracefully (i.e. when TCP or is received). And |since a host cannot possibly send data after sending a TCP |or . It doesn't ever make sense to read after getting an |FD_CLOSE. Why should you? Oh dear - FD_CLOSE wars again. I beleive the reason is that some stacks post FD_CLOSE as soon as the arrives - whether there is still more data to be read in the incoming buffer or not. So getting an FD_CLOSE is no guarantee there is not still more data to read - you must keep reading after FD_CLOSE until recv() returns 0, and then you have truly hit the end of the data stream. | Bob Quinn rcq@ftp.com | FTP Software, Inc. No. Andover, MA So when _exactly_ does FTP's WINSOCK post the FD_CLOSE message ? :-) -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Mon Nov 22 06:11:44 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AB18211; Sun, 21 Nov 1993 19:26:00 -0500 Received: by usage.csd.unsw.OZ.AU id AA22284 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 22 Nov 1993 11:25:29 +1100 Received: by atlas (4.1/1.35) id AA19089; Mon, 22 Nov 93 11:11:44 EST Message-Id: <9311220011.AA19089@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 22 Nov 1993 11:11:44 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: non-blocking lingering close I've been looking at using non-blocking calls, but emulating the behaviour of a blocking close, and have determined there is no real way to do so given the 1.1 interface spec. A "blocking graceful close" is when closesocket is called on a socket with a non-zero linger time, and it should block, waiting for all the buffered outgoing data to be sent and acknowledged before returning. The problem is that there is currently no way to determine if there is still buffered data waiting to be written. Ioctlsocket() has the FIONREAD parameter, to return an indication of data waiting to be read, but there is no corresponding FIONWRITE parameter to determine if buffered data is still waiting to be sent to the remote host, or has not been acknowledged. What are people's thoughts on emulating a lingering close, and whether a new ioctlsocket() parameter could be defined for version 2.0. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From 100121.373@compuserve.com Fri Nov 22 01:38:20 1993 Received: from dub-img-1.compuserve.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA23911; Mon, 22 Nov 1993 06:41:12 -0500 Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam) id GAA20483; Mon, 22 Nov 1993 06:41:11 -0500 Date: 22 Nov 93 06:38:20 EST From: Franck LEFEVRE <100121.373@compuserve.com> To: "INTERNET:winsock-hackers" Cc: "INTERNET:winsock-users@s" , "INTERNET:winsock@sunsite" Subject: WSDIR932 Message-Id: <931122113820_100121.373_BHJ47-1@CompuServe.COM> WSDIR the WinSock directory The WSDIR932 of November 17th, 1993 is now available. The first goal of WSDIR is to provide a regularly-updated directory of WinSock applications, implementations and development tools. It contains only, and will always only contain, data sheets that have been directly filled by poeple responsible for the product submitted. There are 3 official ways to get a copy of WSDIR : 1) K1's BBS (France) (33) 33.39.22.13 Files Area : TCP/IP 2) CompuServe Forum : MSNETWORKS 3) Anonymous FTP to ftp.demon.co.uk:/pub/ibmpc/winsock (thanks, Steve) Franck LEFEVRE K1 Informatique 100121.373@compuserve.com From rcq@ftp.com Mon Nov 22 04:01:18 1993 Received: from ftp.com (babyoil.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA02117; Mon, 22 Nov 1993 09:01:23 -0500 Received: from rcq.oysters.ftp.com by ftp.com via PCMAIL with DMSP id AA07438; Mon, 22 Nov 93 09:01:18 -0500 Date: Mon, 22 Nov 93 09:01:18 -0500 Message-Id: <9311221401.AA07438@ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: non-blocking lingering close From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@ftp.com Repository: babyoil.ftp.com Originating-Client: oysters.ftp.com Hello Paul! > I've been looking at using non-blocking calls, but emulating the behaviour > of a blocking close, and have determined there is no real way to > do so given the 1.1 interface spec. A "blocking graceful close" is when > closesocket is called on a socket with a non-zero linger time, and it > should block, waiting for all the buffered outgoing data to be sent and > acknowledged before returning. Hmm, I think your premise needs further examination. :-) To restate what I believe you are saying, you don't see any way to avoid the possibility of closesocket() blocking. Is that correct? I don't see any problem in the specification. It's not prominent, but page 12 of the spec does say closesocket() "only blocks if SO_LINGER is set." So by default, closesocket() should return immediately and a graceful close should occur in the background. > The problem is that there is currently no way to determine if there > is still buffered data waiting to be written. Ioctlsocket() has the FIONREAD > parameter, to return an indication of data waiting to be read, but there is > no corresponding FIONWRITE parameter to determine if buffered data is still > waiting to be sent to the remote host, or has not been acknowledged. > > What are people's thoughts on emulating a lingering close, and whether > a new ioctlsocket() parameter could be defined for version 2.0. Not a good idea. Our stack, for one, does not have a problem with closes (blocking or not), but we *would* have a problem providing ioctlsocket() FIONWRITE. It's a violation of the API, since it reaches into the stack and (in effect) tells you what TCP data has not been acknowledged yet. It begs for abuse. If you want to avoid a blocking close, and you don't trust the default non-blocking close, there is another option for you. You can do a shutdown() how==1, which sends a TCP *AFTER* all the buffered data is sent and acknowledged (in effect a says "I'm done sending data"). Then you should do recv's (non-blocking and/or with the MSG_PEEK flag set). When recv() returns 0 the graceful close is complete, and it's safe to call closesocket(). Please note, your recv() loop shouldn't be *too* tight (to let other processes breath). You will also want a timeout in case the other side doesn't complete the close (after the timeout period is up, you'd want to set SO_LINGER to 0, and call closesocket() to abort the connection). And you should also be prepared for the possibility of an error back from recv() (like WSACONNRESET, if the other side aborts). This is a legitimate alternative to FIONWRITE. Regards, -- Bob Quinn rcq@ftp.com FTP Softwarde, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Tue Nov 23 07:45:44 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA23361; Mon, 22 Nov 1993 22:40:56 -0500 Received: by usage.csd.unsw.OZ.AU id AA04547 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 23 Nov 1993 14:40:59 +1100 Received: by atlas (4.1/1.35) id AA22280; Tue, 23 Nov 93 12:45:44 EST Message-Id: <9311230145.AA22280@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 23 Nov 1993 12:45:44 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: accepting new connections in the presence of aborted ones. I'm running into problems with a WSAT script, that seems to be assuming different behaviour to my assumptions. Please imagine these two machines execute the following pseudo-calls in time order increasing down the list - calls side-by-side are synchronisation points: Machine 1 Machine 2 s=socket s = socket bind(s, cli_addr) bind(s, servaddr) listen(s,5) connect(s, servaddr) s2=accept(s) { data transfer - after a while, { connection is reset for some reason } { calls on both side return WSAECONNRESET/WSAECONNABORTED } closesocket(s) s2 = socket bind(s2, cli_addr) connect(s2, srv_addr)...(1) closesocket(s2) Because the connection was reset, Machine 1 can bind() immediately to the same source address/port it had before, and tries to connect to the same server address/port as before. Because Machine 2 has not yet closed the socket, the incoming SYN matches the aborted connection. Should machine 2 fail the connection attempt, returnig RST, or create the new connection in the listening queue? I've always assuemd that an incoming segment which exactly matches both addresses and ports is associated with an existing connection if possible and a listening socket if not. At least one WSAT script seems to assume multiple times that the second connect() in the sequence above should succeed. Any thoughts from the protocol and BSD experts out there? -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Tue Nov 23 07:26:00 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA23395; Mon, 22 Nov 1993 22:41:19 -0500 Received: by usage.csd.unsw.OZ.AU id AA04551 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 23 Nov 1993 14:41:00 +1100 Received: by atlas (4.1/1.35) id AA22259; Tue, 23 Nov 93 12:26:00 EST Message-Id: <9311230126.AA22259@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 23 Nov 1993 12:26:00 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: non-blocking lingering close Thus expounded Bob Quinn on Nov 22, 9:15am: /-------------------- |Hello Paul! | |> I've been looking at using non-blocking calls, but emulating the behaviour |> of a blocking close, and have determined there is no real way to |> do so given the 1.1 interface spec. A "blocking graceful close" is when |> closesocket is called on a socket with a non-zero linger time, and it |> should block, waiting for all the buffered outgoing data to be sent and |> acknowledged before returning. | |Hmm, I think your premise needs further examination. :-) |To restate what I believe you are saying, you don't see any |way to avoid the possibility of closesocket() blocking. Is |that correct? Not entirely. I'm fully aware of the semantics on blocking, non-blocking and hard closes and the various combinations of linger settings. What I want to do is emulate the semantics of a lingering blocking graceful closesocket(), without actually blocking inside the implementation. I want to trigger the sending of the FIN in a non-blocking manner, then periodically check for when the connection has been fully gracefully closed, without causing the underlying implementation to block at any time. |I don't see any problem in the specification. It's not prominent, |but page 12 of the spec does say closesocket() "only blocks if |SO_LINGER is set." So by default, closesocket() should return |immediately and a graceful close should occur in the background. Thats right, but then the resourses attache to that socket are not free'ed for some arbitrary time. In particular, its not possible to bind a socket to the same address/port immediately after this form of "background" closesocket without setting SO_REUSEADDR, as there is no way to tell when the connection has been closed, or even if the FIN has reached the remote host yet or not. I want to be able to do: closesocket_equivalent(s1) s2=socket() bind(s2,same_port_as_s1), WITHOUT using the blocking closesocket() by setting a struct linger to {1,something != 0}. |> The problem is that there is currently no way to determine if there |> is still buffered data waiting to be written. Ioctlsocket() has the FIONREAD |> parameter, to return an indication of data waiting to be read, but there is |> no corresponding FIONWRITE parameter to determine if buffered data is still |> waiting to be sent to the remote host, or has not been acknowledged. |> |> What are people's thoughts on emulating a lingering close, and whether |> a new ioctlsocket() parameter could be defined for version 2.0. | |Not a good idea. Our stack, for one, does not have a problem with |closes (blocking or not), but we *would* have a problem providing |ioctlsocket() FIONWRITE. It's a violation of the API, since it |reaches into the stack and (in effect) tells you what TCP data has |not been acknowledged yet. It begs for abuse. "violation of the API"? APIs are defined to be what is found to be useful, and/or in this case largely compatible with BSD code. APIs aren't violated, they are defined. How does knowing how long the retransmission buffer is currently beg for abuse? How is this more abuse than being able to find out how many bytes are waiting to be read, before the recv() call? Please clarify your thoughts on this "abuse.". I thought proposing something like FIONWRITE was pleasing, if only on the grounds of symmetry!. |If you want to avoid a blocking close, and you don't trust the |default non-blocking close, there is another option for you. You |can do a shutdown() how==1, which sends a TCP *AFTER* all |the buffered data is sent and acknowledged (in effect a says |"I'm done sending data"). Then you should do recv's (non-blocking |and/or with the MSG_PEEK flag set). When recv() returns 0 the |graceful close is complete, and it's safe to call closesocket(). Well, if recv() returns anything else except 0 or WSAEWOULDBLOCK the connection has to be reset anyway, just like it does now if closesocket() is called and the receive buffer still contains data. Your proposal doesn't work in general, because the outgoing and incoming data streams are essentially independent. Its quite posible for the remote end to close its end, sending me a FIN, before it has read and acknowledged all the outgoing data in my buffer. Recv() returning zero doesn't tell me diddly about whether it has received all my data or not - you are assuming the only reason it would close is because it has received my FIN, which is not a valid assumption. Do people bother with TIMEWAIT state, and disallowing bind()s for the port during TIMEWAIT? Am I correct that a closesocket() with linger set on (for a long time) should block until the socket exits TIMEWAIT (if it is the first FIN sender)? I decided to use a non-blocking graceful closesocket, let the socket be closed in the background, and loosely loop trying to bind a new socket to the same address until it succeeds. I'm not convinved all the error codes and conditions are covered though. Anybody else with a solution? -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From rcq@ftp.com Tue Nov 23 07:23:21 1993 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AB23261; Tue, 23 Nov 1993 13:32:23 -0500 Received: from rcq.oysters.ftp.com by ftp.com via PCMAIL with DMSP id AA27251; Tue, 23 Nov 93 12:23:21 -0500 Date: Tue, 23 Nov 93 12:23:21 -0500 Message-Id: <9311231723.AA27251@ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: non-blocking lingering close From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@ftp.com Repository: babyoil.ftp.com Originating-Client: oysters.ftp.com Hi Paul! > "violation of the API"? APIs are defined to be what is found to be useful, > and/or in this case largely compatible with BSD code. APIs aren't violated, > they are defined. One of the great advantages of the Windows Sockets API is that it hides low-level details. APIs are indeed defined to be useful, but simplicity has great benefits. Exposing low-level details complicates an API. If its unnecessary, it's a violation. > How does knowing how long the retransmission buffer is currently beg for abuse? > How is this more abuse than being able to find out how many bytes are waiting > to be read, before the recv() call? Please clarify your thoughts on this > "abuse.". Detecting incoming data with FIONREAD is very different than detecting incoming acknowledgments with FIONWRITE. Application developers would get a false sense of security knowing what data has been acknowledged, assuming that is the (only) data received by the other end. If the connection fails, the sender may not see an acknowledgment for data the other end received. > Your proposal doesn't work in general, because the outgoing and incoming data > streams are essentially independent. Its quite posible for the remote end > to close its end, sending me a FIN, before it has read and acknowledged all > the outgoing data in my buffer. One side initiates the close of a TCP socket, not both. If you have called shutdown(how=1), it's valid to expect recv()=0 to indicate the completion of a graceful close. Otherwise you have a seriously broken client/server pair. > Do people bother with TIMEWAIT state, and disallowing bind()s for the port > during TIMEWAIT? Yes. :) > Am I correct that a closesocket() with linger set on (for a long time) > should block until the socket exits TIMEWAIT (if it is the first > FIN sender)? No. And it doesn't matter what the timeout length is. After initiating the close, a blocking closesocket() returns immediately after it receives the TCP . In other words, closesocket() returns at the point the TCP connection enters the TIMEWAIT state. The socket is invalid after the return from closesocket(). But if it just completed a graceful close (that it initiated), the TCP connection still has some life to it. It can send another if the other side missed the first one and sends another . The port used cannot be bound by another socket until this TIMEWAIT state expires. > I decided to use a non-blocking graceful closesocket, let the socket be closed > in the background, and loosely loop trying to bind a new socket to the > same address until it succeeds. I'm not convinved all the error codes and > conditions are covered though. That is a valid strategy, too. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Wed Nov 24 05:16:22 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA28916; Tue, 23 Nov 1993 18:16:23 -0500 Received: by usage.csd.unsw.OZ.AU id AA02215 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 24 Nov 1993 10:16:10 +1100 Received: by atlas (4.1/1.35) id AA25460; Wed, 24 Nov 93 10:16:23 EST Message-Id: <9311232316.AA25460@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 24 Nov 1993 10:16:22 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: non-blocking lingering close Thus expounded Bob Quinn on Nov 23, 3:50pm: /-------------------- |Hi Paul! | |> "violation of the API"? APIs are defined to be what is found to be useful, |> and/or in this case largely compatible with BSD code. APIs aren't violated, |> they are defined. | |One of the great advantages of the Windows Sockets API is that |it hides low-level details. APIs are indeed defined to be useful, |but simplicity has great benefits. Exposing low-level details |complicates an API. Agreed. | If its unnecessary, it's a violation. Thats a bit strong, isn't it? If its unnecessary, its unnecessary, but it isn't broken, and simply "not using" an unnecessary feature is enough to shield you from the consequences. I guess I associate "violation" with phrases/words like "abomination", "blight on the planet", and other fire-and-brimstone concepts! In an ideal API, every part in it is presumably defined because at least someone thought it necessary. That doesn't mean there aren't other features that are necessary, but no-one has thought of them yet. Not that I'm saying FIONWRITE is such a feature, of course! It could be argued that send() and recv() are unnecessary (and hence "violations"), since exactly the same effect can be obtained using sendto() and recvfrom() with NULL address arguments. |Detecting incoming data with FIONREAD is very different than |detecting incoming acknowledgments with FIONWRITE. I didn't want to detect incoming ACKS - that is protocol-specific to TCP, and the sockets paradigm is not. I want to know the length of the outbound data queue, which is not, as far as I know, a concept specific to any stream protocol. For TCP, it is the sum of the data not-yet-sent and the length of the retransmission queue, but the application doesn't need or want to know how its calculated or stored. |One side initiates the close of a TCP socket, not both. If you |have called shutdown(how=1), it's valid to expect recv()=0 to |indicate the completion of a graceful close. Otherwise you have |a seriously broken client/server pair. Rubbish. Its perfectly possible for both sides to close their sending-side simultaneously, or at least before they are aware the other end has done so. Its not the common case, but its possible. In general, either side may shutdown their sending, to indicate "I won't send any more data". If the other end ever reciprocates (and its not guaranteed), yes you will get recv()=0 eventually. If the other end has already closed its end, and is just accepting all the incoming data up to your FIN, you may well read the recv()=0 before the other end has accepted your outgoing data. In short, the world is not limited to using TCP in "client/server" pairs. This has gotten a bit out of hand, Bob - lets take our religious differences to email, and concentrate on the technical issues here! | |> Am I correct that a closesocket() with linger set on (for a long time) |> should block until the socket exits TIMEWAIT (if it is the first |> FIN sender)? | |No. And it doesn't matter what the timeout length is. After |initiating the close, a blocking closesocket() returns immediately |after it receives the TCP . In other words, closesocket() |returns at the point the TCP connection enters the TIMEWAIT state. | |The socket is invalid after the return from closesocket(). But if |it just completed a graceful close (that it initiated), the TCP |connection still has some life to it. It can send another |if the other side missed the first one and sends another . |The port used cannot be bound by another socket until this TIMEWAIT |state expires. Oh! I have been assuming that a blocking lingering closesocket() must block until the socket is fully closed (i.e. right through TIMEWAIT), because only then can you bind() another socket to the same port (without setting SO_REUSEADDR). There are certainly many points in Jim Gilroy's WSAT scripts where he assumes you can create an identical TCP connection (same addresses/ports) immediately after closesocket() returns. How is this different, then, from a non-blocking graceful closesocket()? At least in the non-blocking graceful close your data will be correctly sent if possible, no matter how long it takes, whereas with the blocking graceful close you have no guarantee your data will be sent, because of the possibility of the timeout occuring. >From an application's point of view, picking a timeout value applicable for all the different possiblities of remote host speeds and path speeds that might occur, so that the application works well over ethernet or 300 baud packet radio and still closes connections off in a timely manner without aborting the close process prematurely, is fraught with difficulty, and offends me more than being able to find out the amount of outstanding data (which BTW could be used to judge the average link speed, and hence allow more sensible timeout values for blocking closesocket()s to be chosen!). Bob, any thoughts on the other message I sent, about matching incoming SYN packets with aborted connections? -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Tue Nov 30 11:30:36 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA04606; Tue, 30 Nov 1993 03:02:44 -0500 Received: by usage.csd.unsw.OZ.AU id AA27113 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 30 Nov 1993 16:20:20 +1100 Received: by atlas (4.1/1.35) id AA13318; Tue, 30 Nov 93 16:30:36 EST Message-Id: <9311300530.AA13318@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 30 Nov 1993 16:30:36 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: newsgroup -> email gateway problems? I am seeing many more messages inthe alt.winsock newsgroup than I am from the winsock mailing lists - messages seem to be gated form the mailing list to the newsgroup OK, but news postings don't seem to be gated back to the mailing list. Has anyone else noticed this? -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Tue Nov 30 11:28:24 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA04634; Tue, 30 Nov 1993 03:03:09 -0500 Received: by usage.csd.unsw.OZ.AU id AA27019 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 30 Nov 1993 16:18:14 +1100 Received: by atlas (4.1/1.35) id AA13300; Tue, 30 Nov 93 16:28:24 EST Message-Id: <9311300528.AA13300@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 30 Nov 1993 16:28:24 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: Multiple connect()s with SOCK_DGRAM sockets? What is the feeling of the community in allowing multiple connect() calls on SOCK_DGRAM sockets? I have several conflicting points either way: 1) The Winsock 1.1 manual does not mention the possibility of calling connect() again to change the desired destination endpoint on UDP sockets. 2) My Sun's man-page for connect() indicates that a SOCK_DGRAM socket can be "un-connected" by calling connect() with an invalid address - presumably you can then call connect() with a different valid address. 3) Jim's WSAT scripts seem to want to do exactly this, using a destination sockaddr_in with all fields, including sin_family, set to 0. The Winsock spec. should fail these calls with WSAEAFNOSUPPORT, although Jim assumes they will succeed. 4) Doing the same thing on the Sun (all fields, including family, 0) caused that connect() call to core dump ! 5) Douglas Comer, in "Internetworking with TCP/IP Vol. 3", section 8.17, says that once a UDP socket is connect()ed, it can never again be used to receive datagrams from arbitrary clients - it can never be un-connected. Since I've been informed more than once that the aim is "BSD compatibility", and if the Winsock spec differs from BSD behaviour, the BSD behaviour is what should be followed, I would like to propose some standard behaviour for Windows Sockets implementations, possibly with appropriate text added to the next specification, or any addendum to the current spec. (Wasn't there going to be a document with examples and explanations of some points, for those of us unable to get to the winsock-a-thons for the FD_CLOSE wars and similar?) 1) A connected SOCK_DGRAM socket can be "dis-connected" by calling connect() again with a destination 'name' consisting of address and port containing all zeros, and a valid family for the socket (i.e. "AF_INET / 0 / 0.0.0.0"). 2) A connected SOCK_DGRAM must be dis-connected using this method before it can be re-connected again, to the same or different destination address, otherwise an error code of WSAEISCONN will be returned (just like should happen now). This should retain full compatibility both with the current specification and with BSD sockets. Comments anyone? I would really like to hear how the various implementations currently behave in this regard, and what everyone thinks is a reasonable interpretation of the 5 conflicting points listed above. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From rrealmut@b30po1.pcmail.ingr.com Tue Nov 30 00:58:00 1993 Received: from pcout.pcmail.ingr.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA28635; Tue, 30 Nov 1993 09:58:01 -0500 Received: from hubsmp2.pcmail.ingr.com by pcout.pcmail.ingr.com (5.65c/1.921207) id AA01726; Tue, 30 Nov 1993 08:59:12 -0600 Received: by hubsmp2.pcmail.ingr.com with Microsoft Mail id <2CFB7BD4@hubsmp2.pcmail.ingr.com>; Tue, 30 Nov 93 08:59:00 PST From: "Realmuto, Rob" To: "'SMTP:paul@abccomp.oz.au'" , winsock-hackers Subject: RE: newsgroup -> email gateway problems? Date: Tue, 30 Nov 93 08:58:00 PST Message-Id: <2CFB7BD4@hubsmp2.pcmail.ingr.com> Encoding: 29 TEXT X-Mailer: Microsoft Mail V3.0 I've seen the same thing. --------------------------------------------------------------------- Rob Realmuto | Mail Stop: GD1103 Columbus Lab | E-mail:rrealmut@ingr.com or Intergraph Corporation |rrealmut@b30po1.pcmail.ingr.com Huntsville, Alabama | Telephone: (205) 730-6475 35894-0000 FAX: (205) 730-6000 --------------------------------------------------------------------- ---------- >From: winsock-hackers >To: Multiple recipients of list >Subject: newsgroup -> email gateway problems? >Date: Tuesday, November 30, 1993 3:14AM > >I am seeing many more messages inthe alt.winsock newsgroup than I am from >the winsock mailing lists - messages seem to be gated form the mailing list to >the newsgroup OK, but news postings don't seem to be gated back to >the mailing list. Has anyone else noticed this? > > >-- >Paul Brooks |paul@abccomp.oz.au |Emerging Standard: >TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet >579 Harris St., Ultimo | | been superseded. >Sydney Australia 2007 |ph: +61 2 281 3155 | > From jskohl@srv.pacbell.com Tue Nov 30 00:29:33 1993 Received: from ns.PacBell.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA08514; Tue, 30 Nov 1993 11:32:33 -0500 Received: from srv.PacBell.COM (mother.srv.PacBell.COM) by ns.PacBell.COM (4.1/PacBell-10/26/93) id AA23941; Tue, 30 Nov 93 08:32:31 PST Received: from sbhp1.srv.pacbell.com by srv.PacBell.COM (4.1/SMI-4.0) id AA21591; Tue, 30 Nov 93 08:32:30 PST Received: by sbhp1.srv.pacbell.com (1.37.109.4/16.2) id AA16986; Tue, 30 Nov 93 08:29:33 -0800 From: Jeff Kohl Message-Id: <9311301629.AA16986@sbhp1.srv.pacbell.com> Subject: unsubscribe To: winsock-hackers@sunsite.unc.edu Date: Tue, 30 Nov 93 8:29:33 PST X-Hpvue$Revision: 1.8 $ Mime-Version: 1.0 Content-Type: Message/rfc822 X-Vue-Mime-Level: 4 Mailer: Elm [revision: 70.85] content-type:text/plain;charset=us-ascii mime-version:1.0 Please unsubscribe me From rcq@ftp.com Tue Nov 30 07:12:32 1993 Received: from ftp.com (babyoil.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA12840; Tue, 30 Nov 1993 12:12:56 -0500 Received: from rcq.oysters.ftp.com by ftp.com via PCMAIL with DMSP id AA22885; Tue, 30 Nov 93 12:12:32 -0500 Date: Tue, 30 Nov 93 12:12:32 -0500 Message-Id: <9311301712.AA22885@ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: Multiple connect()s with SOCK_DGRAM sockets? From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@ftp.com Repository: babyoil.ftp.com Originating-Client: oysters.ftp.com Hi Paul! > What is the feeling of the community in allowing multiple connect() calls > on SOCK_DGRAM sockets? I have several conflicting points either way: ... > Since I've been informed more than once that the aim is "BSD compatibility", > and if the Winsock spec differs from BSD behaviour, the BSD behaviour is what > should be followed, I would like to propose some standard behaviour for Agreed. > 1) A connected SOCK_DGRAM socket can be "dis-connected" by calling > connect() again with a destination 'name' consisting of address and > port containing all zeros, and a valid family for the socket > (i.e. "AF_INET / 0 / 0.0.0.0"). The address 0.0.0.0 is the value for INADDR_ANY which should cause connect() to fail with WSAEDESTADDRREQ. What about using INADDR_NONE instead? > 2) A connected SOCK_DGRAM must be dis-connected using this method before > it can be re-connected again, to the same or different destination > address, otherwise an error code of WSAEISCONN will be returned > (just like should happen now). Why should you have to disconnect, it's not like there's a real connection to close? All a UDP connect() does is change the foreign IP Address and/or foreign port in the "association" (the 5-tuple of Protocol, Local IP Addr, Local Port, Foreign IP Addr and Foreign Port). I can't think of any reason why it should fail, as long as they provide a valid foreign address (i.e. an address other than 0.0.0.0). Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Wed Dec 1 04:14:07 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP id AA19150; Tue, 30 Nov 1993 17:27:36 -0500 Received: by usage.csd.unsw.OZ.AU id AA19038 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 1 Dec 1993 09:27:03 +1100 Received: by atlas (4.1/1.35) id AA15251; Wed, 1 Dec 93 09:14:08 EST Message-Id: <9311302214.AA15251@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 1 Dec 1993 09:14:07 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: Multiple connect()s with SOCK_DGRAM sockets? Thus expounded Bob Quinn on Nov 30,12:36pm: /-------------------- |Hi Paul! Hi Bob! | |> What is the feeling of the community in allowing multiple connect() calls |> on SOCK_DGRAM sockets? I have several conflicting points either way: |.. |> Since I've been informed more than once that the aim is "BSD compatibility", |> and if the Winsock spec differs from BSD behaviour, the BSD behaviour is what |> should be followed, I would like to propose some standard behaviour for | |Agreed. | |> 1) A connected SOCK_DGRAM socket can be "dis-connected" by calling |> connect() again with a destination 'name' consisting of address and |> port containing all zeros, and a valid family for the socket |> (i.e. "AF_INET / 0 / 0.0.0.0"). | |The address 0.0.0.0 is the value for INADDR_ANY which should cause |connect() to fail with WSAEDESTADDRREQ. What about using INADDR_NONE |instead? Well, INADDR_NONE has the same value as INADDR_BROADCAST, which we must allow for UDP sockets to "connect" to the broadcast address. It won't be able to receive anything (since no valid datagrams have the broadcast address as the source address) but it will be able to broadcast without using sendto(), which I feel is allowable. I don't particularly care what value is used, but I'm not keen on using 'any invalid address' as the BSD man-pages seem to suggest. Yes, the Winsock 1.1 spec says an address of all zeros should return WSAEADDRNOTAVAIL, but I've made a note in my copy to bring up for the next version that I feel this should be for SOCK_STREAM sockets only. |> 2) A connected SOCK_DGRAM must be dis-connected using this method before |> it can be re-connected again, to the same or different destination |> address, otherwise an error code of WSAEISCONN will be returned |> (just like should happen now). | |Why should you have to disconnect, it's not like there's a real |connection to close? All a UDP connect() does is change the foreign |IP Address and/or foreign port in the "association" (the 5-tuple of |Protocol, Local IP Addr, Local Port, Foreign IP Addr and Foreign Port). |I can't think of any reason why it should fail, as long as they |provide a valid foreign address (i.e. an address other than 0.0.0.0). I agree wholeheartedly - this part was purely to follow the "BSD sockets is King", which seems to mandate that it must be "dis-connected" before being "re-connected". There is no real reason why, except compatibility to Berkeley Sockets, and following what seems to be common practise. I'll propose a similar question in c.p.tcp-ip, to gain a wider audience in what is "supposed" to happen. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 |