From paul@atlas.dev.abccomp.oz.au Mon May 2 06:58:25 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20261; Sun, 1 May 1994 21:45:11 -0400 Received: by usage.csd.unsw.OZ.AU id AA29480 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 2 May 1994 11:44:55 +1000 Received: by atlas (4.1/1.35) id AA02541; Mon, 2 May 94 11:58:26 EST Message-Id: <9405020158.AA02541@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 2 May 1994 11:58:25 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: jobrien@mcs.umes.umd.edu, Multiple recipients of list Subject: Re: FD_READ @ recv() Thus expounded "James M. O'Brien, Jr" on Apr 30, 1:31pm: /-------------------- |I've been working with WSAAsyncSelect and FD_READ. Attempting |to make wsfinger an async client. I've been able to do this but I've |found one glitch I am not sure that either I am handling correclt or its |not completely obvious to me. | |As an example: | |Once I've connected, I use WSAAsyncSelect to set the socket to NB |and I want FD_READ.... | |In the wndproc I handle FD_READ and call recv() once for each |FD_READ received. Where it appears to become grey, how does one |handle the end of a data stream? As in receiving a reply from a finger |server, its not readily apparent, how one would recognize that the |stream is EOF. With finger, the server closes its end of the connection after sending the response string. In your case, you will get FD_READ messages to indicate there is data waiting to be read, but when the end-of-connection FIN arrives, the DLL would like to post you FD_CLOSE to tell you so - it should NOT post FD_READ as well (which the stacks you work on seem to be doing!). Your solution is to call WSAAsyncSelect with interest in both FD_READ and FD_CLOSE. That way you will get the FD_CLOSE message when the data stream has ended. -- 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 bruce@isi.FrontierTech.COM Mon May 2 02:38:15 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25266; Mon, 2 May 1994 09:38:05 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA05589; Mon, 2 May 94 08:37:00 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DC5105A-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Mon, 02 May 94 08:38:15 CST Subject: Re: Curious behaviour from winsock To: rcq@ftp.com Cc: Multiple recipients of list Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII > >> >... assuming your application initiated the close (called >> >closesocket() first), then you'd be in FIN_WAIT. On page 91 in the >> >documentation for WSAAsyncSelect() the spec says "The FD_CLOSE is >> >posted when the connection goes into FIN_WAIT or CLOSE_WAIT states." >> >> That same documentation says "Closing a socket with closesocket() also >> cancels WSAAsyncSelect() message sending" (p. 89). I've always felt that >> once closesocket() is called, the descriptor is invalid, and a DLL >> shouldn't post messages containing invalid descriptors. > >Clearly then, the portions we've each quoted contradict each other. > >> The FD_CLOSE would be redundant, anyway, wouldn't it? It was the >> application that initiated the close, so it should already know about it, >> right? > >No, it's not redundant. Calling closesocket() will *send* the FIN >and the FD_CLOSE is posted when you *recieve* the FIN in response. > Sending the FIN would put the connection in FIN_WAIT state, so the FD_CLOSE would, theoretically, be posted immediately in closesocket(). So, when the app calls closesocket, it knows that it "should" get an FD_CLOSE and can act accordingly (or post itself the FD_CLOSE, if it really wants to go that route). **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 **************************************** From rcq@mailserv-D.ftp.com Mon May 2 10:36:39 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20128; Mon, 2 May 1994 14:37:54 -0400 Received: from ftp.com by ftp.com ; Mon, 2 May 1994 14:37:52 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 2 May 1994 14:37:52 -0400 Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24786; Mon, 2 May 94 14:36:39 EDT Date: Mon, 2 May 94 14:36:39 EDT Message-Id: <9405021836.AA24786@mailserv-D.ftp.com> To: Bruce@isi.FrontierTech.COM Subject: Re: Curious behaviour from winsock From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: winsock-hackers@sunsite.unc.edu Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon May 2 14:36:31 1994] Originating-Client: sidearm.ftp.com Content-Length: 2139 > >> >... assuming your application initiated the close (called > >> >closesocket() first), then you'd be in FIN_WAIT. On page 91 in the > >> >documentation for WSAAsyncSelect() the spec says "The FD_CLOSE is > >> >posted when the connection goes into FIN_WAIT or CLOSE_WAIT states." > >> > >> That same documentation says "Closing a socket with closesocket() also > >> cancels WSAAsyncSelect() message sending" (p. 89). I've always felt > that > >> once closesocket() is called, the descriptor is invalid, and a DLL > >> shouldn't post messages containing invalid descriptors. > > > >Clearly then, the portions we've each quoted contradict each other. > > > >> The FD_CLOSE would be redundant, anyway, wouldn't it? It was the > >> application that initiated the close, so it should already know about > it, > >> right? > > > >No, it's not redundant. Calling closesocket() will *send* the FIN > >and the FD_CLOSE is posted when you *recieve* the FIN in response. > > > > Sending the FIN would put the connection in FIN_WAIT state, so the > FD_CLOSE would, theoretically, be posted immediately in closesocket(). > So, when the app calls closesocket, it knows that it "should" get an > FD_CLOSE and can act accordingly (or post itself the FD_CLOSE, if it > really wants to go that route). My error, you are right. Now I realize how totally useless FD_CLOSE is for sockets that are initiating the close. Water under the bridge at this point, but to be consistent, the way it *should* have worked is you'd get FD_CLOSE when it goes into TIME_WAIT not CLOSE_WAIT (in other words when it *receives* a FIN, not when it *sends* the FIN). This way it would be symmetrical with the other case, when a connected socket enters CLOSE_WAIT upon receipt of a FIN. This way it would be useful, too. So, in the final analysis on a non-blocking close there's no way for you to know if you completed a gracefully or not. Does this sound broken to anyone else but me? -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From william@sybase.com Mon May 2 05:00:56 1994 Received: from halon.sybase.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24570; Mon, 2 May 1994 15:00:38 -0400 Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0) id AA10205; Mon, 2 May 1994 12:03:27 +0800 Received: from mercury.sybgate.sybase.com (mercury-1) by sybase.com (4.1/SMI-4.1/SybH3.3) id AA11248; Mon, 2 May 94 12:00:33 PDT Received: by mercury.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.2) id AA25723; Mon, 2 May 94 12:00:56 PDT From: william@sybase.com (William Wong) Message-Id: <9405021900.AA25723@mercury.sybgate.sybase.com> Subject: Re: WSAStartup() question To: winsock-hackers@SunSITE.Unc.EDU Date: Mon, 2 May 94 12:00:56 PDT In-Reply-To: <9404211502.AA01502@MIT.EDU>; from "winsock-hackers@SunSITE.Unc.EDU" at Apr 30, 94 1:18 pm X-Mailer: ELM [version 2.3 PL0] Content-Length: 1143 > > Suppose I have the following application structure: > > > > --------------------- > my.exe > --------------------- > | | > | | > | | > ^ ^ > ------------ --------------- > auth.dll gen.dll > ------------ --------------- > | | > | | > | | > ----------------- > winsock.dll > ----------------- > > > Should I call WSAStartup() in my.exe and not in the other two DLLs or > should I call it in auth.dll and gen.dll? Can WSACleanup() be called in a > wep()? What are the advantages/disavantages? > > The 1.1 spec clearly states that WSAStartup()/WSACleanup() are used on per-task basis. You can call them anywhere in your exe/dlls as long as you know which task the WSAStartup()/WSACleanup() are referring to. In your setup, I would say do it in my.exe would be easiest. You can do it in your dlls too; however, you will have to build a task table to keep track of the details. May I suggest you create another DLL that deals with Winsock exclusively and have your auth.dll and gen.dll interact with it? It makes thing much simpler and clearer. William -- william@sybase.com From william@sybase.com Mon May 2 05:14:13 1994 Received: from halon.sybase.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA27329; Mon, 2 May 1994 15:13:52 -0400 Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0) id AA10741; Mon, 2 May 1994 12:16:40 +0800 Received: from mercury.sybgate.sybase.com (mercury-1) by sybase.com (4.1/SMI-4.1/SybH3.3) id AA12227; Mon, 2 May 94 12:13:49 PDT Received: by mercury.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.2) id AA27022; Mon, 2 May 94 12:14:14 PDT From: william@sybase.com (William Wong) Message-Id: <9405021914.AA27022@mercury.sybgate.sybase.com> Subject: Re: Q: How to connect with a timeout ? To: winsock-hackers@SunSITE.Unc.EDU (Roger Kries) Date: Mon, 2 May 94 12:14:13 PDT In-Reply-To: <199404181056.AA20414@SunSITE.Unc.EDU>; from "Roger Kries" at Apr 30, 94 12:07 pm X-Mailer: ELM [version 2.3 PL0] Content-Length: 780 > > If at the moment of the connect call, the remote machine has no socket > created that listens to the specified port, the following select() call > will always timeout, even if during the timeout interval a program is > started that listens to the port. That means that in the case where a > blocking connect call would return ECONNREFUSED, a non-blocking returns > WSAWOULDBLOCK, but the select call always timeouts. > > So how can I find out if the remote machine is listening to a specific > TCP port without blocking and in a Berkley Socket compatible manner? > > Any suggestions are welcome. Thanx in advance. > You can always do your own clock counting. Call select() with zero timeout in a loop that you do the timeout logic. William -- william@sybase.com From william@sybase.com Mon May 2 05:06:58 1994 Received: from halon.sybase.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08836; Mon, 2 May 1994 16:09:54 -0400 Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0) id AA10530; Mon, 2 May 1994 12:09:26 +0800 Received: from mercury.sybgate.sybase.com (mercury-1) by sybase.com (4.1/SMI-4.1/SybH3.3) id AA11760; Mon, 2 May 94 12:06:34 PDT Received: by mercury.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.2) id AA26521; Mon, 2 May 94 12:06:58 PDT From: william@sybase.com (William Wong) Message-Id: <9405021906.AA26521@mercury.sybgate.sybase.com> Subject: Re: Essential Winsock problems To: winsock-hackers@SunSITE.Unc.EDU (Franklin S. Cheng) Date: Mon, 2 May 94 12:06:58 PDT In-Reply-To: <9404210528.AA09209@ee.tamu.edu>; from "Franklin S. Cheng" at Apr 30, 94 12:56 pm X-Mailer: ELM [version 2.3 PL0] Content-Length: 0 > > > Dear hackers, > > I have an essential winsock problem : what will happen when my > program keeps running(never return) while monitoring FD_READ by using > WSAsynchSelect(), can winsock.dll or the real TCP/IP stacks > receive the incoming packets ? My doubt is if the real IP-layer > receives packets by interrupt or from Windows 'pseudo' multitasking ? > If it's the latter, of course , not to mention it. > > thanks, > Franklin. > You will have to yield back to Windows somehow if you use WSAAsyncSelect(). The Winsock would have to somehow post message to you to notify you the arrival of the data. It can do it if you are hogging the Windows system. William -- william@sybase.com From Abtin_Assadi/HQ/3Com@3mail.3com.com Mon May 2 22:43:05 1994 Received: from relay2.UU.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA17447; Mon, 2 May 1994 22:43:05 -0400 Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwofq04864; Mon, 2 May 94 22:43:02 -0400 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA24809; Mon, 2 May 94 19:44:11 PDT Received: from notes.DEV.3Com.COM by gw.3Com.COM with SMTP id AA09166 (5.65c/IDA-1.4.4 for ); Mon, 2 May 1994 19:42:59 -0700 Return-Path: Received: by notes.dev.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.0)/1.0) id AA0813; Mon, 02 May 94 19:52:11 -0700 Message-Id: <9405030252.AA0813@notes.dev.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id 089413E25709A59D882560430077FC3E; Mon, 2 May 94 19:52:11 To: Multiple recipients of list From: Abtin Assadi/HQ/3Com Date: 2 May 94 14:51:33 PS Subject: unsubscribe Mime-Version: 1.0 Content-Type: Text/Plain From johnt@unipalm.co.uk Tue May 3 05:26:18 1994 Received: from unipalm.co.uk (unipalm.unipalm.co.uk) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08966; Tue, 3 May 1994 05:26:18 -0400 Received: from brimstone.unipalm.co.uk by unipalm.co.uk (4.1/SMI-4.1 (unipalm 1.17)) id AA26841; Tue, 3 May 94 10:25:27 BST Received: from dreft.unipalm.co.uk by brimstone.unipalm.co.uk (4.1/SMI-4.1 brimstone 1.19) id AA25600; Tue, 3 May 94 10:26:11 BST Message-Id: In-Reply-To: <9404270457.AA15202@atlas> References: Conversation <9404270457.AA15202@atlas> with last message <9404270457.AA15202@atlas> Priority: Normal To: paul@atlas.abccomp.oz.au, Multiple recipients of list Reply-To: johnt@unipalm.co.uk Mime-Version: 1.0 From: John Taylor Subject: Re: FW: What's happening here? Date: Tue, 03 May 94 10:34:17 BST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"; X-MAPIrenderingpos=0xFFFFFFFF Content-Transfer-Encoding: quoted-printable On Sat, 30 Apr 94 18:49:40 BST paul@atlas.abccomp.oz.au Wrote: > Thus expounded paul@atlas on Apr 26, 6:32pm: > /-------------------- > | > |Assuming port 1111 is the server port, and 1026 is your Winsock's port= , > |this looks like a TCP bug. In the second line (the first 1026->1111 = packet) > |the ACK field should be set to the previous SEQ field+1. Because its = not, > |the remote machine is aborting the connection and returning a RST. > > etc. > > Anyone know which 'white hole' this message came from? I dimly > remember sending this many months ago, and don't remember if it was > seen on the list back then, but it certainly aint recent! > Wierd. Something strange seems to be going on. I've not seen much traffic on the winsock-hackers list, then suddenly = today I got about thirty messages all at once, including some threads of severa= l messages. Is there a logjam somewhere ? Regards John Taylor johnt@unipalm.co.uk +44 223 250100 From a16903@itesocci.gdl.iteso.mx Mon May 2 15:32:57 1994 Received: from itesocci ([148.201.1.4]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00488; Tue, 3 May 1994 08:00:32 -0400 Received: by itesocci (4.1/SMI-4.1) id AA27170; Mon, 2 May 94 21:32:58 CST From: a16903@itesocci.gdl.iteso.mx (Torres De Niz Vicente) Message-Id: <9405030332.AA27170@itesocci> Subject: Sending a Broadcast To: winsock-hackers@sunsite.unc.edu Date: Mon, 2 May 1994 21:32:57 -0600 (CST) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 515 Hi everybody: Just one question: actually i'm developing a program that tries to send a broacast over the net, i'm using in the socket definition the datagram option and in the socket's options the one related with broad- cast (SO_BROADCAST). In the destination address i'm using the INET_BROADCAST defined in the winsock.h as 0xffffffff. In both programs i'm using the same port and they are running over a novell netware v 3.11 What i'm doing wrong ? Vicente Torres de Niz a16903@itesocci.gdl.iteso.mx From wilson@ftp.com Wed May 4 05:23:56 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11012; Wed, 4 May 1994 09:24:56 -0400 Received: by ftp.com ; Wed, 4 May 1994 09:23:56 -0400 Received: by ftp.com ; Wed, 4 May 1994 09:23:56 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405041323.AA24311@ftp.com> Subject: Re: Curious behaviour from winsock To: Bruce@isi.FrontierTech.COM Date: Wed, 4 May 1994 09:23:56 -0400 (EDT) Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <2DC5105A-00000001@Bruces.FrontierTech.COM> from "Bruce@isi.FrontierTech.COM" at May 4, 94 03:29:24 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1565 >> Sending the FIN would put the connection in FIN_WAIT state, so the >> FD_CLOSE would, theoretically, be posted immediately in closesocket(). What purpose does this serve? To validate that you really did close the socket? ;-) IMHO, the spec is broken is this respect, because it says (these are from memory): 1. calling closesocket() cancels all async notification 2. the stack gets a FD_CLOSE at FIN_WAIT In the case where you call closesocket(), which takes precedence? Since you called closesocket(), you shouldn't expect to see any more messages on a socket ... certainly not on a socket descriptor that is no longer a legal descriptor (by the very fact that you called closesocket()). In addition, why would you want the FIN_WAIT notification? You knew you called closesocket() ... >> So, when the app calls closesocket, it knows that it "should" get an >> FD_CLOSE and can act accordingly (or post itself the FD_CLOSE, if it >> really wants to go that route). A straw example, at best. The application could have a function to do it's cleanup, which could be called after closesocket() or after getting an FD_CLOSE notification. Going through the OS to make the entry point common is only necessary to make the code look a little bit cleaner. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN From wilson@ftp.com Wed May 4 05:27:36 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11531; Wed, 4 May 1994 09:27:39 -0400 Received: by ftp.com ; Wed, 4 May 1994 09:27:36 -0400 Received: by ftp.com ; Wed, 4 May 1994 09:27:36 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405041327.AA24392@ftp.com> Subject: Re: Curious behaviour from winsock To: rcq@ftp.com Date: Wed, 4 May 1994 09:27:36 -0400 (EDT) Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9405021836.AA24786@mailserv-D.ftp.com> from "Bob Quinn" at May 4, 94 03:31:30 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1218 >> So, in the final analysis on a non-blocking close there's no way >> for you to know if you completed a gracefully or not. Does this >> sound broken to anyone else but me? Other than the "peace of mind" argument you gave me in the office ;-), I can't see any reason. If the app is interested, it can call the blocking close. Like it or not, the paradigm says that a socket descriptor becomes invalid when you call closesocket(). It seems broken IMHO to send messages on an already closed socket. There is always the case of fixing the spec and then, if the app writer is truly interested, calling shutdown() on the write side of the socket and waiting for the FD_CLOSE, then closing the socket. Without the spec in my hand (where did that go? ;-), I can't tell if that scenario is quite possible / plausible with the current wording of the spec. It certainly seems like a 2.0 issue to me (did I say that? ;-) -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN From bruce@isi.FrontierTech.COM Wed May 4 02:41:14 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13918; Wed, 4 May 1994 09:40:51 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA04266; Wed, 4 May 94 08:39:44 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DC7B40C-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Wed, 04 May 94 08:41:14 CST Subject: FD_CLOSE after closesocket (was: Curious behaviour from winsock) To: winsock-hackers@sunsite.unc.edu Cc: wilson@ftp.com (Brad Wilson) Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII (in reply to Brad Wilson's message, quoted below) It sort of sounds like you're agreeing with me, that the FD_CLOSE is unnecessary after the closesocket. I think the statement that closesocket cancels async notifications takes precedence, and if an app really needs to find out if the connection closed gracefully, it should hang onto the descriptor, use shutdown(1) to send a FIN, then read to EOF. IMHO, calling closesocket says "I am done with this socket, and have no further interest in anything associated with it." I still maintain that closesocket invalidates the descriptor and what would an app do if it didn't get the FD_CLOSE it expected? Reset the connection? It can't, because it has no reference to the connection now that the socket descriptor is gone. It might display a warning to the user, but since it can't take any meaningful steps to correct the problem, this would amount to "I've fallen, and I can't get up!" --------------------------------- Brad Wilson wrote: >>> Sending the FIN would put the connection in FIN_WAIT state, so the >>> FD_CLOSE would, theoretically, be posted immediately in closesocket(). > >What purpose does this serve? To validate that you really did close the >socket? ;-) IMHO, the spec is broken is this respect, because it says >(these are from memory): > > 1. calling closesocket() cancels all async notification > 2. the stack gets a FD_CLOSE at FIN_WAIT > >In the case where you call closesocket(), which takes precedence? Since >you called closesocket(), you shouldn't expect to see any more messages >on a socket ... certainly not on a socket descriptor that is no longer >a legal descriptor (by the very fact that you called closesocket()). > >In addition, why would you want the FIN_WAIT notification? You knew >you called closesocket() ... > >>> So, when the app calls closesocket, it knows that it "should" get an >>> FD_CLOSE and can act accordingly (or post itself the FD_CLOSE, if it >>> really wants to go that route). > >A straw example, at best. The application could have a function to do >it's cleanup, which could be called after closesocket() or after getting >an FD_CLOSE notification. Going through the OS to make the entry point >common is only necessary to make the code look a little bit cleaner. > **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 **************************************** From wilson@ftp.com Wed May 4 05:55:14 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AD16518; Wed, 4 May 1994 09:55:22 -0400 Received: by ftp.com ; Wed, 4 May 1994 09:55:14 -0400 Received: by ftp.com ; Wed, 4 May 1994 09:55:14 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405041355.AA25656@ftp.com> Subject: Re: FD_CLOSE after closesocket (was: Curious behaviour from winsock) To: Bruce@isi.FrontierTech.COM Date: Wed, 4 May 1994 09:55:14 -0400 (EDT) Cc: winsock-hackers@sunsite.unc.edu, wilson@ftp.com In-Reply-To: <2DC7B40C-00000001@Bruces.FrontierTech.COM> from "Bruce@isi.FrontierTech.COM" at May 4, 94 08:41:14 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 707 >> It sort of sounds like you're agreeing with me, that the FD_CLOSE is >> unnecessary after the closesocket. I think the statement that closesocket >> cancels async notifications takes precedence, and if an app really needs >> to find out if the connection closed gracefully, it should hang onto the >> descriptor, use shutdown(1) to send a FIN, then read to EOF. This seems reasonable and correct to me. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN From rcq@mailserv-D.ftp.com Wed May 4 13:53:43 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA23846; Wed, 4 May 1994 17:55:02 -0400 Received: from ftp.com by ftp.com ; Wed, 4 May 1994 17:54:58 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 4 May 1994 17:54:58 -0400 Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA23621; Wed, 4 May 94 17:53:43 EDT Date: Wed, 4 May 94 17:53:43 EDT Message-Id: <9405042153.AA23621@mailserv-D.ftp.com> To: Bruce@isi.FrontierTech.COM Subject: Re: FD_CLOSE after closesocket (was: Curious behaviour from winsock) From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed May 4 17:53:29 1994] Originating-Client: sidearm.ftp.com Content-Length: 2927 > It sort of sounds like you're agreeing with me, that the FD_CLOSE is > unnecessary after the closesocket. I think the statement that closesocket > cancels async notifications takes precedence, So we're faced then with either having the spec say that: - FD_CLOSE doesn't occur *at all* on a socket that initiates the close (with shutdown() or with closesocket()), since in effect it just tells you something you already know. OR - FD_CLOSE does *not* occur after calling closesocket() to initiate the close of a TCP connection, but it *does* occur after calling shutdown() That's about as transparent as my cafe latte. > and if an app really needs > to find out if the connection closed gracefully, it should hang onto the > descriptor, use shutdown(1) to send a FIN, then read to EOF. I couldn't agree with this more. The problem is that most people don't know this method, as evidenced by most WinSock applications around these days. > IMHO, > calling closesocket says "I am done with this socket, and have no further > interest in anything associated with it." I agree, but I don't want to. As is, the specification says this, yes. IMNSHO, you *should* be able to post a message (FD_CLOSE only, not FD_READ or others) for a socket that has been closed by closesocket(). As we all know, every application is *required* to expect receipt of messages on a socket even after the socket has been closed. This is because of the latency between the posting and receipt of messages. In other words, there is always the chance of as yet unprocessed messages in your queue when you call closesocket(). So what? So, I (still) think that FD_CLOSE is broken if it doesn't tell you when you reach TIME_WAIT instead of CLOSE_WAIT. WinSock should indeed tell you when the close is complete. Not just cuz I like the warm and fuzzy feeling I get knowing a connection closed gracefully, but also because it's easy to write an application that works with this and it satisfies my insatiable desire for a logical and symmetrical world (which is--amazingly enough--possible in the computer software realm). > I still maintain that closesocket invalidates the descriptor and what > would an app do if it didn't get the FD_CLOSE it expected? Reset the > connection? It can't, because it has no reference to the connection now > that the socket descriptor is gone. It might display a warning to the > user, but since it can't take any meaningful steps to correct the problem, > this would amount to "I've fallen, and I can't get up!" As much as I like that error message, I think it might be more meaningful to a user to say something like "the connection on the remote host was disconnected unexpectedly". Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From bruce@isi.FrontierTech.COM Wed May 4 11:20:23 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA29086; Wed, 4 May 1994 18:20:39 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA05570; Wed, 4 May 94 17:18:57 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DC82DBA-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Wed, 04 May 94 17:20:23 CST Subject: Re: FD_CLOSE after closesocket (was: Curious behaviour from winsock) To: rcq@ftp.com Cc: Multiple recipients of list Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII >So we're faced then with either having the spec say that: > - FD_CLOSE doesn't occur *at all* on a socket that initiates the close > (with shutdown() or with closesocket()), since in effect it just > tells you something you already know. > OR > - FD_CLOSE does *not* occur after calling closesocket() to initiate the > close of a TCP connection, but it *does* occur after calling > shutdown() > >That's about as transparent as my cafe latte. > I don't have a problem with it. You get an FD_CLOSE when a _socket_ goes into FIN_WAIT state. After a closesocket the socket does not exist (altho the connection might), so you won't get any more messages. >> and if an app really needs >> to find out if the connection closed gracefully, it should hang onto >> the >> descriptor, use shutdown(1) to send a FIN, then read to EOF. > >I couldn't agree with this more. The problem is that most people >don't know this method, as evidenced by most WinSock applications >around these days. OK, so maybe we need to throw a mention of it in the FAQ. >> I still maintain that closesocket invalidates the descriptor and what >> would an app do if it didn't get the FD_CLOSE it expected? Reset the >> connection? It can't, because it has no reference to the connection >> now >> that the socket descriptor is gone. It might display a warning to >> the >> user, but since it can't take any meaningful steps to correct the >> problem, >> this would amount to "I've fallen, and I can't get up!" > >As much as I like that error message, I think it might be more >meaningful to a user to say something like "the connection on >the remote host was disconnected unexpectedly". > Actually, the app _didn't get an FD_CLOSE, so the message would be more like "the connection on the remote host unexpectedly didn't disconnect". Huh? :) I still don't know what meaningful action an app could take based on the knowledge that the connection associated with a nonexistant socket has been closed. **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 **************************************** From paul@atlas.dev.abccomp.oz.au Thu May 5 04:41:05 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11095; Wed, 4 May 1994 19:28:02 -0400 Received: by usage.csd.unsw.OZ.AU id AA19815 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Thu, 5 May 1994 09:27:28 +1000 Received: by atlas (4.1/1.35) id AA15570; Thu, 5 May 94 09:41:07 EST Message-Id: <9405042341.AA15570@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 5 May 1994 09:41:05 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: Curious behaviour from winsock Thus expounded Bob Quinn on May 4, 3:33am: /-------------------- |So, in the final analysis on a non-blocking close there's no way |for you to know if you completed a gracefully or not. Does this |sound broken to anyone else but me? Well, sortof. Closesocket() is, by default, a non-blocking graceful disconnect - the disconnecting happens 'in the background' (which would be interesting to guarantee if the application then calls WSACleanup immediately, then the DLL unloads, but thats another thread :-). I always assumed that an application calling closesocket() in this way didn;t really care whether it actually happened gracefully or not - in most cases the upper layer protocol knows whether all the data that matters was received or not. I always thought that an application that cared whether the disconnect really was graceful would call shutdown(), than wait for an FD_CLOSE to arrive indicating the remote end had closed, or use a lingering closesocket() with a longish timeout. One could argue that the paragraph under WSAAsyncSelect that begins "The error code in an FD_CLOSE message indicates whether the socket close was graceful or abortive" would mandate that FD_CLOSE is NOT posted as soon as the application calls closesocket() or shutdown(), because the DLL doesn't know yet whether the close will work properly, and so can't tell yet what error code to post. In fact, I beleive the semantics you want can be acheived if, in the bit that says "...FD_CLOSE is posted when the connection goes into the FIN_WAIT or CLOSE_WAIT states", the "FIN_WAIT" is interpreted as a typo, and should have been "TIME_WAIT" :-) The next sentence "This results from the remote end performing a shutdown() on the send side or a closesocket()" shows that the intent of the wording, previous sentence not withstanding, is for FD_CLOSE to be posted when the remote end's FIN arrives, NOT as soon as the local app calls closesocket()/shutdown(). My Conclusion: The quoted portions are 2:1 in favour of posting FD_CLOSE when the remote'd FIN arrives, NOT when the local app calls shutdown/closesocket. Any stack that does not behave so is only 33% WinSock compliant w.r.t. FD_CLOSE, and we should be as understanding as possible of the confusion. -- 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 Thu May 5 04:52:46 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12889; Wed, 4 May 1994 19:38:44 -0400 Received: by usage.csd.unsw.OZ.AU id AA20378 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Thu, 5 May 1994 09:39:06 +1000 Received: by atlas (4.1/1.35) id AA15610; Thu, 5 May 94 09:52:47 EST Message-Id: <9405042352.AA15610@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 5 May 1994 09:52:46 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: paul@atlas.abccomp.oz.au, Multiple recipients of list Subject: Re: Q: How to connect with a timeout ? > > If at the moment of the connect call, the remote machine has no socket > created that listens to the specified port, the following select() call > will always timeout, even if during the timeout interval a program is > started that listens to the port. That means that in the case where a > blocking connect call would return ECONNREFUSED, a non-blocking returns > WSAWOULDBLOCK, but the select call always timeouts. > > So how can I find out if the remote machine is listening to a specific > TCP port without blocking and in a Berkley Socket compatible manner? > > Any suggestions are welcome. Thanx in advance. If the call fails because the remote end refused it, then the socket should be enabled in the EXCEPTFDS fd_set. Try placing the socket of interest in both the 'writefds' set (to be triggered if the connection is successful) and the 'exceptfds' set (to be triggered if the copnnection is refused). select() should not timeout in this case except if the remote host is really unreachable (and the connection takes a couple of minutes before giving up trying to send the SYN). Note also that it is possible, and recommended somewhere I can't place at the moment, for sockets to _keep trying_ in the face of incoming RST segments, on the basis that there may be a synchronisation problem or a slow server or something, and the intended server socket has just been slow to be opened. In this case, even with returned RST segments, it will _appear_ to be the same as when the remote is truly unreachable , except when the connection attempt finally times out you will get WSAECONNREFUSED instead of WSAEHOSTUNREACH as an error 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 Thu May 5 04:55:47 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13414; Wed, 4 May 1994 19:41:43 -0400 Received: by usage.csd.unsw.OZ.AU id AA20492 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Thu, 5 May 1994 09:42:05 +1000 Received: by atlas (4.1/1.35) id AA15627; Thu, 5 May 94 09:55:48 EST Message-Id: <9405042355.AA15627@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 5 May 1994 09:55:47 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: a16903@itesocci.gdl.iteso.mx, Multiple recipients of list Subject: Re: Sending a Broadcast Thus expounded Torres De Niz Vicente on May 4, 3:55am: /-------------------- | Hi everybody: | | Just one question: actually i'm developing a program that tries to |send a broacast over the net, i'm using in the socket definition the |datagram option and in the socket's options the one related with broad- |cast (SO_BROADCAST). | | In the destination address i'm using the INET_BROADCAST defined |in the winsock.h as 0xffffffff. In both programs i'm using the same port |and they are running over a novell netware v 3.11 | | What i'm doing wrong ? Err - you haven't told us what problem you're having! What happens (or doesn't happen) next ? -- 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 a16903@itesocci.gdl.iteso.mx Wed May 4 14:32:14 1994 Received: from itesocci (itesocci.gdl.iteso.mx) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25010; Wed, 4 May 1994 23:28:02 -0400 Received: by itesocci (4.1/SMI-4.1) id AA21157; Wed, 4 May 94 20:32:16 CST From: a16903@itesocci.gdl.iteso.mx (Torres De Niz Vicente) Message-Id: <9405050232.AA21157@itesocci> Subject: Sending a Broadcast To: winsock-hackers@sunsite.unc.edu Date: Wed, 4 May 1994 20:32:14 -0600 (CST) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 626 | | Just one question: actually i'm developing a program that tries to |send a broacast over the net, i'm using in the socket definition the |datagram option and in the socket's options the one related with broad- |cast (SO_BROADCAST). | | In the destination address i'm using the INET_BROADCAST defined |in the winsock.h as 0xffffffff. In both programs i'm using the same port |and they are running over a novell netware v 3.11 | | What i'm doing wrong ? Err - you haven't told us what problem you're having! Sorry, the receiving program never gets the broadcast, it seem that the broadcast do not travel in the network From rcq@mailserv-D.ftp.com Wed May 4 19:50:53 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA27847; Wed, 4 May 1994 23:52:09 -0400 Received: from ftp.com by ftp.com ; Wed, 4 May 1994 23:52:08 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 4 May 1994 23:52:08 -0400 Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA25953; Wed, 4 May 94 23:50:53 EDT Date: Wed, 4 May 94 23:50:53 EDT Message-Id: <9405050350.AA25953@mailserv-D.ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: Curious behaviour from winsock From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed May 4 23:50:42 1994] Originating-Client: sidearm.ftp.com Content-Length: 3196 > |So, in the final analysis on a non-blocking close there's no way > |for you to know if you completed a gracefully or not. Does this > |sound broken to anyone else but me? > > Well, sortof. Closesocket() is, by default, a non-blocking graceful > disconnect - the disconnecting happens 'in the background' (which would > be interesting to guarantee if the application then calls WSACleanup > immediately, then the DLL unloads, but thats another thread :-). I always > assumed that an application calling closesocket() in this way didn;t really > care whether it actually happened gracefully or not - in most cases the > upper layer protocol knows whether all the data that matters was received > or not. > I always thought that an application that cared whether the disconnect > really was graceful would call shutdown(), than wait for an FD_CLOSE > to arrive indicating the remote end had closed, or use a lingering > closesocket() with a longish timeout. I always thought that too, but after Bruce's persistence now I realize that it's not defined this way (though it should be). You get the FD_CLOSE when the socket goes into FIN_WAIT ...which is just after you *send* the FIN, not when you recieve it (which would be when it enters TIME_WAIT). Stupid? Yup. There's no sense asking to be told something you already know. > One could argue that the paragraph under WSAAsyncSelect that begins > "The error code in an FD_CLOSE message indicates whether the socket > close was graceful or abortive" would mandate that FD_CLOSE is > NOT posted as soon as the application calls closesocket() or shutdown(), > because the DLL doesn't know yet whether the close will work properly, > and so can't tell yet what error code to post. > In fact, I beleive the semantics you want can be acheived if, in the > bit that says "...FD_CLOSE is posted when the connection goes into the > FIN_WAIT or CLOSE_WAIT states", the "FIN_WAIT" is interpreted as a typo, > and should have been "TIME_WAIT" :-) Exactamundo. > The next sentence "This results from the remote end performing a > shutdown() on the send side or a closesocket()" shows that the intent of > the wording, previous sentence not withstanding, is for FD_CLOSE > to be posted when the remote end's FIN arrives, NOT as soon as the > local app calls closesocket()/shutdown(). I feel like one of those dogs in the back of a car window on a bumpy road, my head bobbing up and down in agreement. These two lines you've quoted obviously contradict each other. > My Conclusion: The quoted portions are 2:1 in favour of posting FD_CLOSE > when the remote'd FIN arrives, NOT when the local app calls > shutdown/closesocket. Any stack that does not behave so is > only 33% WinSock compliant w.r.t. FD_CLOSE, and we should be > as understanding as possible of the confusion. This sounds like fodder for the ambiguities group (or whatever it's called) for WinSock 2. Boy, won't that be a fun group. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From bruce@isi.FrontierTech.COM Thu May 5 02:26:49 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA04180; Thu, 5 May 1994 09:59:23 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA06913; Thu, 5 May 94 08:25:17 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DC9022B-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Thu, 05 May 94 08:26:49 CST Subject: Re: Curious behaviour from winsock To: Multiple recipients of list Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII >> I always thought that an application that cared whether the disconnect >> really was graceful would call shutdown(), than wait for an FD_CLOSE >> to arrive indicating the remote end had closed, or use a lingering >> closesocket() with a longish timeout. > >I always thought that too, but after Bruce's persistence now I >realize that it's not defined this way (though it should be). >You get the FD_CLOSE when the socket goes into FIN_WAIT ...which >is just after you *send* the FIN, not when you recieve it (which >would be when it enters TIME_WAIT). Stupid? Yup. There's no >sense asking to be told something you already know. > [stuff deleted]. >> In fact, I beleive the semantics you want can be acheived if, in the >> bit that says "...FD_CLOSE is posted when the connection goes into the >> FIN_WAIT or CLOSE_WAIT states", the "FIN_WAIT" is interpreted as a typo, >> and should have been "TIME_WAIT" :-) > >Exactamundo. > I agree that it would make more sense to post when the connection goes to TIME_WAIT, otherwise even the shutdown() sequence won't work properly because there's no way to reenable FD_CLOSE. My objections have been to the posting of that message after a closesocket() call. >> My Conclusion: The quoted portions are 2:1 in favour of posting FD_CLOSE >> when the remote'd FIN arrives, NOT when the local app calls >> shutdown/closesocket. Any stack that does not behave so is >> only 33% WinSock compliant w.r.t. FD_CLOSE, and we should be >> as understanding as possible of the confusion. > Unfortunately, the 33% which that stack agrees with is the most explicit reference, and the others could possibly be interpreted in different ways to support either side of the argument. >This sounds like fodder for the ambiguities group (or whatever >it's called) for WinSock 2. Boy, won't that be a fun group. Yes and yes. **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 **************************************** From paul@atlas.dev.abccomp.oz.au Fri May 6 04:39:54 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10053; Thu, 5 May 1994 19:25:55 -0400 Received: by usage.csd.unsw.OZ.AU id AA15780 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Fri, 6 May 1994 09:26:16 +1000 Received: by atlas (4.1/1.35) id AA19876; Fri, 6 May 94 09:39:55 EST Message-Id: <9405052339.AA19876@atlas> From: paul@atlas.abccomp.oz.au Date: Fri, 6 May 1994 09:39:54 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Multiple recipients of list Subject: When to post FD_CLOSE (was Re: Curious behaviour from winsock Cc: rcq@ftp.com Thus expounded Bob Quinn on May 4,11:50pm: /-------------------- note: | xxx = Bob |> xxx = me [after an anlysis on why itis not possible to know whether a close was gracefully successful or abortive ] |I always thought that too, but after Bruce's persistence now I |realize that it's not defined this way (though it should be). |You get the FD_CLOSE when the socket goes into FIN_WAIT ...which |is just after you *send* the FIN, not when you recieve it (which |would be when it enters TIME_WAIT). Stupid? Yup. There's no |sense asking to be told something you already know. | |> One could argue that the paragraph under WSAAsyncSelect that begins |> "The error code in an FD_CLOSE message indicates whether the socket |> close was graceful or abortive" would mandate that FD_CLOSE is |> NOT posted as soon as the application calls closesocket() or shutdown(), |> because the DLL doesn't know yet whether the close will work properly, |> and so can't tell yet what error code to post. |> In fact, I beleive the semantics you want can be acheived if, in the |> bit that says "...FD_CLOSE is posted when the connection goes into the |> FIN_WAIT or CLOSE_WAIT states", the "FIN_WAIT" is interpreted as a typo, |> and should have been "TIME_WAIT" :-) | |Exactamundo. | |This sounds like fodder for the ambiguities group (or whatever |it's called) for WinSock 2. Boy, won't that be a fun group. I wouldn't miss it for anything, although I don't think it will be any more enjoyable than a dentist visit. In this case, though, I don't feel that there will be too many problems. In over an hour of coming up with various scenarios, I can't find one situation where an application written to the spec as it is interpreted now will be disadvantaged if the FD_CLOSE is not posted until just slightly later than some stacks are doing, based on the FIN_WAIT/CLOSE_WAIT paragraph, which has been taken too literally by most of us - probably because it mentioned concrete examples of when to do something, so we all thought it would be easier to beleive it than to think of what the correct behaviour might be based on a more vague paragraph. If the FD_CLOSE is not posted until the remote's FIN/ACK arrives, I don't feel that _any_ existing code will break, so the "FIN_WAIT" can be altered to read "TIME_WAIT" in everybodies copies of Winsock 1.1 without any drama at all. If _anybody_ can think of a code sequence that won't work correctly under this change, please post it. I don't feel very comfortable with the approach, but it could be argued that, since the other paragraphs and sentences, although a little more vague, contradict this one, it should never have been interpreted as correct by right-thinking people in the first place (by a form of logic known as "majority rules" :^P ) Note that I don't beleive FD_CLOSE should be posted in either FIN_WAIT_1 OR FIN_WAIT_2 - after sending the local FIN, both the remote ends ACK and FIN should be received before posting FD_CLOSE (which is when the stack enters TIME_WAIT). Note 2: I'm sure its not a good idea to be scattering details that may or may not apply to implementations internally within a spec of this sort, mandating the internal structure. I don't think talking about when to post FD_CLOSE in terms of internal states, particularly when they are specific to TCP/IP, is very smart at all, and the whole paragraph will have to be re-written to support a more protocol-neutral approach when WinSock/IPX and WinSock/Appletalk are being discussed. Again: can anybody else think of any way that an application might break if I alter our Winsock so that FD_CLOSE is posted when the remote end's FIN arrives - that is, in CLOSE_WAIT or TIME_WAIT, _not_ FIN_WAIT ? -- 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 Fri May 6 05:15:58 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA16895; Thu, 5 May 1994 20:02:34 -0400 Received: by usage.csd.unsw.OZ.AU id AA17267 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Fri, 6 May 1994 10:02:23 +1000 Received: by atlas (4.1/1.35) id AA20074; Fri, 6 May 94 10:16:00 EST Message-Id: <9405060016.AA20074@atlas> From: paul@atlas.abccomp.oz.au Date: Fri, 6 May 1994 10:15:58 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Bruce@isi.frontiertech.com, Multiple recipients of list Subject: Re: Curious behaviour from winsock Thus expounded Bruce@isi.FrontierTech.COM on May 5,10:05am: /-------------------- | |>> My Conclusion: The quoted portions are 2:1 in favour of posting |FD_CLOSE |>> when the remote'd FIN arrives, NOT when the local app calls |>> shutdown/closesocket. Any stack that does not behave so is |>> only 33% WinSock compliant w.r.t. FD_CLOSE, and we should be |>> as understanding as possible of the confusion. |> |Unfortunately, the 33% which that stack agrees with is the most explicit |reference, and the others could possibly be interpreted in different ways |to support either side of the argument. Bruce, Sorry, but I'm a bit dozy this morning. How can the paragraph starting "The error code in an FD_CLOSE message ..." and the sentence "This results from the remote end performing a shutdown() on the send side or a closesocket()." be interpreted as supporting the premise that FD_CLOSE should be posted in FIN_WAIT - that is, as soon as the relevent call is made, possibly even before the FIN packet has gone out onto the wire? Inquiring minds, etc... -- 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 bruce@isi.FrontierTech.COM Fri May 6 02:35:17 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11541; Fri, 6 May 1994 09:34:44 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA08817; Fri, 6 May 94 08:32:54 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DCA55A8-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Fri, 06 May 94 08:35:17 CST Subject: Re: Curious behaviour from winsock To: Multiple recipients of list Cc: paul@atlas.abccomp.oz.au Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII > How can the paragraph starting "The error code in an FD_CLOSE >message ..." and the sentence "This results from the remote end performing >a shutdown() on the send side or a closesocket()." be interpreted as >supporting the premise that FD_CLOSE should be posted in FIN_WAIT - that is, >as soon as the relevent call is made, possibly even before the FIN packet >has gone out onto the wire? > When I wrote that, I was thinking someone who really wanted to split hairs could argue that it doesn't specify that the closesocket occurred on the remote (you could insert pauses at creative places to imply that the closesocket could be on either end). Unfortunately, that would *also* conflict with the statement that closesocket cancels notifictations! I have no problem with posting in TIME_WAIT, but I do have a problem with branding stacks "noncompliant" because they followed an explicit statement in the spec (a statement which, ironically, was supposed to *reduce* confusion : > ). **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 *************************************** From davidtr@microsoft.com Sun May 8 03:48:00 1994 Received: from netmail2.microsoft.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15295; Sun, 8 May 1994 13:49:10 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA05837; Sun, 8 May 94 09:50:40 -0700 Received: by netmail2 using fxenixd 1.0 Sun, 08 May 94 09:50:40 PDT Message-Id: <9405081749.AA28050@itgmsm> From: davidtr@microsoft.com To: winsock-hackers@SunSITE.Unc.EDU Subject: RE: When to post FD_CLOSE (was Re: Curious behaviour from winsock Date: Sun, 08 May 94 10:48:00 PDT X-Mailer: Microsoft Mail V3.0 |From: netmail!paul@atlas.abccomp.oz.au | | In over an hour of coming up with various scenarios, I can't find |one situation where an application written to the spec as it is interpreted |now will be disadvantaged if the FD_CLOSE is not posted until just slightly |later than some stacks are doing, based on the FIN_WAIT/CLOSE_WAIT |paragraph, which has been taken too literally by most of us - probably |because it mentioned concrete examples of when to do something, so we all |thought it would be easier to beleive it than to think of what the correct |behaviour might be based on a more vague paragraph. If the FD_CLOSE is not |posted until the remote's FIN/ACK arrives, I don't feel that _any_ existing |code will break, so the "FIN_WAIT" can be altered to read "TIME_WAIT" in |everybodies copies of Winsock 1.1 without any drama at all. imho, paul is correct that an FD_CLOSE is posted when a FIN arrives, not when the local app does a closesocket() (which disables message posting anyway) or a shutdown() of the send side. as others have said, there isn't any value in telling the app that it just did a shutdown(). therefore, the statement about FIN_WAIT is incorrect; it should say TIME_WAIT. |Note 2: I'm sure its not a good idea to be scattering details that may |or may not apply to implementations internally within a spec of this |sort, mandating the internal structure. I don't think talking about |when to post FD_CLOSE in terms of internal states, particularly when they |are specific to TCP/IP, is very smart at all, and the whole |paragraph will have to be re-written to support a more protocol-neutral |approach when WinSock/IPX and WinSock/Appletalk are being discussed. right again, paul. the addition of that statement was supposed to clear up the confusion, but it has caused much more confusion and headache than it relieved. live and learn. |Again: can anybody else think of any way that an application might break |if I alter our Winsock so that FD_CLOSE is posted when the remote |end's FIN arrives - that is, in CLOSE_WAIT or TIME_WAIT, _not_ FIN_WAIT ? i cannot. davidtr@microsoft.com From wilson@ftp.com Sun May 8 12:35:57 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AB08521; Sun, 8 May 1994 16:36:00 -0400 Received: by ftp.com ; Sun, 8 May 1994 16:35:57 -0400 Received: by ftp.com ; Sun, 8 May 1994 16:35:57 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405082035.AA16845@ftp.com> Subject: Re: When to post FD_CLOSE (was Re: Curious behaviour from winsock To: davidtr@microsoft.com Date: Sun, 8 May 1994 16:35:57 -0400 (EDT) Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9405081749.AA28050@itgmsm> from "davidtr@microsoft.com" at May 8, 94 04:07:27 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1575 netmail!paul@atlas.abccomp.oz.au said... >> |Note 2: I'm sure its not a good idea to be scattering details that may >> |or may not apply to implementations internally within a spec of this >> |sort, mandating the internal structure. I don't think talking about >> |when to post FD_CLOSE in terms of internal states, particularly when they >> |are specific to TCP/IP, is very smart at all, and the whole >> |paragraph will have to be re-written to support a more protocol-neutral >> |approach when WinSock/IPX and WinSock/Appletalk are being discussed. davidtr@microsoft.com said back... >> right again, paul. the addition of that statement was supposed to clear up >> the confusion, but it has caused much more confusion and headache than it >> relieved. live and learn. We do have an emperical problem here, though. For any protocol in which there is a Berkeley implementation (such as TCP/IP), we need to document what Berkeley does so that implementers will stick as closely to BSD as possible. In this one case, there is no problem since there is no WSAAsyncSelect in Unix. ;-) However, we should be on the lookout to not become too general or vague with 2.0 because of the problem I mentioned. Where there are no footsteps, though, we may trod at will! ;-) -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN From paul@atlas.dev.abccomp.oz.au Mon May 9 11:27:00 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11327; Mon, 9 May 1994 02:13:24 -0400 Received: by usage.csd.unsw.OZ.AU id AA21672 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 9 May 1994 16:13:18 +1000 Received: by atlas (4.1/1.35) id AA29899; Mon, 9 May 94 16:27:01 EST Message-Id: <9405090627.AA29899@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 9 May 1994 16:27:00 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: wilson@ftp.com, Multiple recipients of list Subject: Re: When to post FD_CLOSE (was Re: Curious behaviour from winsock Thus expounded Brad Wilson on May 8,10:55pm: /-------------------- |netmail!paul@atlas.abccomp.oz.au said... | |>> |Note 2: I'm sure its not a good idea to be scattering details that may |>> |or may not apply to implementations internally within a spec of this |>> |sort, mandating the internal structure. I don't think talking about |>> |when to post FD_CLOSE in terms of internal states, particularly when they |>> |are specific to TCP/IP, is very smart at all, and the whole |>> |paragraph will have to be re-written to support a more protocol-neutral |>> |approach when WinSock/IPX and WinSock/Appletalk are being discussed. | |davidtr@microsoft.com said back... | |>> right again, paul. the addition of that statement was supposed to clear up |>> the confusion, but it has caused much more confusion and headache than it |>> relieved. live and learn. | |We do have an emperical problem here, though. For any protocol in which |there is a Berkeley implementation (such as TCP/IP), we need to document |what Berkeley does so that implementers will stick as closely to BSD as |possible. In this one case, there is no problem since there is no |WSAAsyncSelect in Unix. ;-) However, we should be on the lookout to not |become too general or vague with 2.0 because of the problem I mentioned. | |Where there are no footsteps, though, we may trod at will! ;-) Absolutely, although I would replace the "Berkeley" with "defacto standard", since WinSock 2.0 will be dealing with protocols, an dprobably more API functions, for which there is no analog within BSD. Hmm - this is much the same sort of comment as I started with above - we have a recursive discussion here! The problem, as I see it, is that this (FD_CLOSE at FIN_WAIT) problem is not the sort of problem that will be picked up by reading drafts, etc - it will/was only picked up when people started trying to _implement_ it with real code. I can only assume that most vendors had their WSAAsyncSelect postings working fairly well before the paragraph under discussion was inserted in the text, and no-one bothered to try to re-implement the semantics to see if they still made sense. I'm concerned that the proposed time frames for Winsock 2.0 are not nearly long enough for all the proposed changes and extensions to be coded by at least three parties and widely tested, in the time-honoured and emminently sensible Internet Way. This is the _only_ way we will make sure that all parts of the new spec. make sense and are implementable. There is not, for example, any "Winsock-a-thons" considered at the moment within the proposed "Timeframes" - something as important as Winsock 2.0, now that the commercial applications are being feverishly written, I would expect to require at least 2 winsock-a-thons to be bedded down properly before declaring the "final" Winsock 2.0 spec. Or are we expecting version 2.0 to be as quickly superseded by 2.1 as Winsock 1.0 was by 1.1? -- 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@mailserv-D.ftp.com Mon May 9 07:48:13 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AB06496; Mon, 9 May 1994 11:49:33 -0400 Received: from ftp.com by ftp.com ; Mon, 9 May 1994 11:49:31 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 9 May 1994 11:49:31 -0400 Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29762; Mon, 9 May 94 11:48:13 EDT Date: Mon, 9 May 94 11:48:13 EDT Message-Id: <9405091548.AA29762@mailserv-D.ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: When to post FD_CLOSE (was Re: Curious behaviour from winsock From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon May 9 11:48:11 1994] Originating-Client: sidearm.ftp.com Content-Length: 1213 > I'm concerned that the proposed time frames for Winsock 2.0 are > not nearly long enough for all the proposed changes and extensions to be > coded by at least three parties and widely tested, in the time-honoured > and emminently sensible Internet Way. This is the _only_ way we will > make sure that all parts of the new spec. make sense and are implementable. > There is not, for example, any "Winsock-a-thons" considered at the moment > within the proposed "Timeframes" - something as important as Winsock 2.0, > now that the commercial applications are being feverishly written, I > would expect to require at least 2 winsock-a-thons to be bedded down > properly before declaring the "final" Winsock 2.0 spec. I'm not an official spokesman by any means, so I won't go into any detail. Suffice it to say that an ambitious, though realistic, schedule for WinSock 2.0 was drafted at the meeting at Interop on May 3rd. Implementation revelations and interoperability testing were among the considerations. I'm sure you'll hear more real soon now :-) -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From mll@gnfile.dk Wed May 11 17:01:41 1994 Received: from ns.dknet.dk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07523; Wed, 11 May 1994 05:09:38 -0400 Received: from gnfile by ns.dknet.dk with UUCP id AA00724 (5.65c8/IDA-1.4.4j for winsock-hackers@sunsite.unc.edu); Wed, 11 May 1994 11:09:29 +0200 Received: by gnfile.dk ( 5.52 (84)/j1.1.2) id AA11867; Wed, 11 May 94 15:01:41 +0200 Date: Wed, 11 May 94 15:01:41 +0200 From: mll@gnfile.dk (Michael Larsen) Message-Id: <9405111301.AA11867@gnfile.dk> To: winsock-hackers@sunsite.unc.edu Subject: unsubscribe X-Charset: ASCII X-Char-Esc: 29 From David_B_Andersen@ccm.jf.intel.com Wed May 11 02:31:30 1994 Received: from ormail.intel.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA17043; Wed, 11 May 1994 13:33:01 -0400 Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0q1I83-000MPnC; Wed, 11 May 94 10:31 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 11 May 94 10:31:30 PST Date: Wed, 11 May 94 10:31:30 PST From: David B Andersen Message-Id: <940511103130_5@ccm.hf.intel.com> To: winsock-hackers@sunsite.unc.edu Subject: Re[2]: When to post FD_CLOSE (was Re: Curious behaviour from >From Paul Brooks: I'm concerned that the proposed time frames for Winsock 2.0 are not nearly long enough for all the proposed changes and extensions to be coded by at least three parties and widely tested, in the time-honoured and emminently sensible Internet Way. This is the _only_ way we will make sure that all parts of the new spec. make sense and are implementable. There is not, for example, any "Winsock-a-thons" considered at the moment within the proposed "Timeframes" - something as important as Winsock 2.0, now that the commercial applications are being feverishly written, I would expect to require at least 2 winsock-a-thons to be bedded down properly before declaring the "final" Winsock 2.0 spec. Or are we expecting version 2.0 to be as quickly superseded by 2.1 as Winsock 1.0 was by 1.1? Good news, Paul. At the Interop Winsock 2 meeting, we explicitly recognized the need for at least two interoperability trials prior to finalizing Winsock 2. Per my notes, these are tentatively scheduled for Jan and March of '95. --Dave Andersen Intel Architecture Labs From sharp@btcs.bt.co.uk Fri May 13 11:52:13 1994 Received: from zaphod.axion.bt.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA17587; Fri, 13 May 1994 08:32:29 -0400 Received: from uugate.rtf.bt.co.uk by zaphod.axion.bt.co.uk id ; Fri, 13 May 1994 13:31:39 +0100 From: Jon Sharp Message-Id: <20116.9405130952@bscsq1.rtf.bt.co.uk> Subject: unsubscribe To: winsock-hackers@sunsite.unc.edu Date: Fri, 13 May 1994 10:52:13 +0100 (WET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 166 -- Jon Sharp Syntegra - BT, Brighton Systems Centre sharp@btcs.bt.co.uk ***************************************************************************** From phe@farallon.com Sun May 18 03:03:03 1994 Received: from farallon.farallon.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15590; Wed, 18 May 1994 11:00:27 -0400 Received: from waygate.farallon.com ([163.176.8.12]) by farallon.farallon.com (4.1/SMI-4.1) id AA02130; Wed, 18 May 94 08:00:23 PDT Message-Id: <9405181500.AA02130@farallon.farallon.com> Date: 18 May 1994 10:03:03 -0700 From: "Ping He" Subject: Message vs. Callback and others Return-Receipt-To: "Ping He" To: "Multiple recipients of list" Hi: Since winsock only support messaging to handle its incoming and outgoing data flow, everything stops when a system modal dialog box pups up. ( in Windows 3.x environment). A callback mechanism would handle this. Question: 1. Is there a tricky way to send and receive data even though a system modal dialog box is on the screen? 2. Will Winsock version 2 provide callbacks? By calling ioctlsocket(), one can check to see exactly how many bytes can be read without blocking, is there a way to check exactly how many bytes one can wirte without blocking instead of checking the return value after issuing a blind send? (select() only provides readability and writability) Talking about select(), has anyone tried MS Winsock VxD beta 2 for WFW? I think their select() is broken. It doesn't return if there is no data to read when one checks the readability for a socket. Fine, but it doesn't return either later when some data comes in. So it never returns. I have sent a bug report about 10 days ago, but have not got any anwser back yet. Does any one have the similar experience? Ping He Farallon Computing, Inc. 1321 Wakarusa Dr. Suite 2010 Lawrence, KS 66049 (913)843-8101 From tcemail!is3.indy.tce.com!FisherM@uunet.uu.net Wed May 18 05:02:00 1994 Received: from relay3.UU.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA28705; Wed, 18 May 1994 13:34:00 -0400 Received: from uucp6.UU.NET by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24500; Wed, 18 May 94 13:33:59 -0400 Received: from tcemail.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Wed, 18 May 1994 13:34:00 -0400 Reply-To: tcemail!FisherM@is3.indy.tce.com Received: from MSMAIL.INDY.TCE.COM (157.254.98.63) by nipper.indy.tce.com (PMDF #12222) id <01HCHFNPPGFK8WWPD0@nipper.indy.tce.com>; Wed, 18 May 1994 12:05 EST Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <2DDA6556@MSMAIL.INDY.TCE.COM>; Wed, 18 May 94 11:58:30 PDT Date: Wed, 18 May 94 12:02:00 PDT From: Fisher Mark Subject: RE: MS Beta 2 select() broken? (was: RE: Message vs. Callback and others) To: WinSock-Hackers Message-Id: <2DDA6556@MSMAIL.INDY.TCE.COM> Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 In message <9405181500.AA02130@farallon.farallon.com> "Ping He" noted possible problems in the MS Winsock VxD beta 2: >Talking about select(), has anyone tried MS Winsock VxD beta 2 for WFW? I >think their select() is broken. It doesn't return if there is no data to read when >one checks the readability for a socket. Fine, but it doesn't return either >later when some data comes in. So it never returns. I have sent a bug report >about 10 days ago, but have not got any anwser back yet. Does any one have the >similar experience? Just yesterday I helped two users set up beta 2. For one user I ran FTP and TELNET as tests. For the second user, I ran HCL's FTP, TELNET, and eXceed/W X Window server. I know that eXceed/W uses select() from tracking DLL calls via WinScope. My suspicion is that under his setup, select() works OK. Any other users care to comment? ====================================================================== Mark Fisher Thomson Consumer Electronics fisherm@tcemail.indy.tce.com Indianapolis, IN "Just as you should not underestimate the bandwidth of a station wagon traveling 65 mph filled with 8mm tapes, you should not overestimate the bandwidth of FTP by mail."