From iblenke@x102a.ess.harris.com Sat Oct 2 16:08:21 1993 Received: from ess.harris.com (su15a.ess.harris.com) by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA03137; Sat, 2 Oct 93 16:08:21 EDT Received: from x102a (x102a.ess.harris.com) by ess.harris.com (4.1/SMI-4.0) id AA18501; Sat, 2 Oct 93 16:08:16 EDT Received: by x102a (5.58/HARRIS-4.0) id AA28865; Sat, 2 Oct 93 16:10:23 EDT Date: Sat, 2 Oct 93 16:10:23 EDT From: iblenke@x102a.ess.harris.com (blenke john 59108) Message-Id: <9310022010.AA28865@x102a> To: winsock-hackers@sunsite.unc.edu Subject: Re: Closure during FD_ACCEPT Gus Estrella wrote: > Now, what would happen if I kepp [sic] tracvk [sic] of the incoming request > (FD_ACCEPT) and before I get to accept it, the client decides to drop the > connection. Will I get an FD_CLOSE message on the listening socket? Good question. I believe that the accept() call would fail with a WSAEWOULDBLOCK if there are no connections to be accepted. Until you actually accept a connection, the WinSock subsystem doesn't consider the connection valid. So, in this case, I wouldn't think that you should receive an FD_CLOSE message. Any arguements to the contrary? If there is nothing for accept to connect to, and it is in non-blocking mode, the spec says: (WinSock v1.1 spec, pg 20 accept()) "WSAEWOULDBLOCK The socket is marked as non-blocking and no connections are present to be accepted." Perhaps someone can explain exactly what WSAEMFILE means? /* ______________________________________________________________________ |Ian C. Blenke 20 | INTERNET: iblenke@rhino.ess.harris.com | _ _ | |Temporary at Large| harris.iblenke@ic1d.harris.com |_| |_| | | |Harris CCS | UNIX/Windows scholar, Internaut. |_/\/\/\|_| |Melbourne, Fla. | Clearly, bordom hath taken over. | |_| |_| | |__________________|_________________________________________|_________| */ /* What demented Microsoft designer decided to make VBFireEvent() crash indeterminately?!!?! Argh! */ From alun@huey.wst.com Tue Oct 5 16:07:49 1993 Received: from huey.wst.com by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA00319; Tue, 5 Oct 93 16:07:49 EDT Received: from lucifer (lucifer.wst.com) by huey.wst.com (4.1/SMI-4.1) id AA15479; Tue, 5 Oct 93 15:09:28 CDT Message-Id: <9310052009.AA15479@huey.wst.com> Date: Tue Oct 05 15:06:46 1993 From: alun@huey.wst.com To: winsock-hackers@sunsite.unc.edu Subject: The closesocket and shutdown routines Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Cc: alun@huey.wst.com I am having some difficulty in deciding whether I should shutdown or closesocket or both, when I have finished (for example) an FTP data transfer in stream mode. To someone new to socket programming in toto (such as myself), the manual is unclear, stating a brief description of each function, but not going into enough detail as to which should be used for what effect. What I think I have worked out is that you can't shutdown after a closesocket, and you can't send or recv after a shutdown with the appropriate value. Would someone please enlighten me? Thanks, Alun. ~~~~ P.S. I have a secure version of ftpd working now, and will be adding to the error checks in the insecure version soon. Look for new versions by the end of the week! From jeffya@spot.protools.com Tue Oct 5 19:20:21 1993 Received: from relay1.UU.NET by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA15268; Tue, 5 Oct 93 19:20:21 EDT Received: from spot.protools.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09425; Tue, 5 Oct 93 19:20:12 -0400 Received: from cc:Mail by spot.protools.com (1.30/SMTPLink) id A02054; Tue, 05 Oct 93 16:20:40 PST Date: Tue, 05 Oct 93 16:20:40 PST From: Jeff Yarnell Message-Id: <9310051620.A02054@spot.protools.com> To: winsock-hackers@sunsite.unc.edu Subject: subscribe From jeffya@spot.protools.com Tue Oct 5 19:21:42 1993 Received: from relay1.UU.NET by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA15352; Tue, 5 Oct 93 19:21:42 EDT Received: from spot.protools.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09876; Tue, 5 Oct 93 19:21:29 -0400 Received: from cc:Mail by spot.protools.com (1.30/SMTPLink) id A02055; Tue, 05 Oct 93 16:21:55 PST Date: Tue, 05 Oct 93 16:21:55 PST From: Jeff Yarnell Message-Id: <9310051621.A02055@spot.protools.com> To: winsock-hackers@sunsite.unc.edu Subject: my apologies about the inappropriate subscribe From gloster@inference.com Fri Oct 8 06:09:59 1993 Received: from fourier.inference.com by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA15574; Fri, 8 Oct 93 06:09:59 EDT Received: from quaestor ([192.12.140.197]) by fourier.inference.com (4.1/SMI-4.1) id AA23155; Fri, 8 Oct 93 03:08:14 PDT Received: by quaestor (4.1/SMI-4.1) id AA23312; Fri, 8 Oct 93 03:11:08 PDT Date: Fri, 8 Oct 93 03:11:08 PDT From: gloster@inference.com (Vance M. Gloster) Message-Id: <9310081011.AA23312@quaestor> To: winsock-hackers@sunsite.unc.edu In-Reply-To: Ed Wilkinson's message of Mon, 4 Oct 93 18:06:32 EDT Subject: looking for best winsock stack out there Which is the most reliable Winsock stack out there? We're developing with one stack which has a couple of bugs, and would like to find out which manufacturer has the most stable bugfree implementation. Thanks in advance, I have found the Windows NT WinSock stack and development environment to be MUCH better than any Windows 3.1-based environment. I never had to reboot even once! The worst was when I got it really fouled up and the stack (or possibly the server I was testing with) took about 4 minutes to reset itself. -Vance Gloster gloster@inference.com From James=L.=Weaver@nectech.com Fri Oct 8 06:39:15 1993 Received: from nectech.com (milkyway.nectech.com) by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA16594; Fri, 8 Oct 93 06:39:15 EDT Received: from CS011.nectech.com by nectech.com with SMTP (5.65/29-nectech) id AA28474; Fri, 8 Oct 93 06:23:53 -0400 Return-Path: Message-Id: <9310081023.AA28474@nectech.com> Received: by CS011.nectech.com with VINES ; Fri, 8 Oct 93 06:37:33 EDT Date: Fri, 8 Oct 93 06:37:28 EDT From: James=L.=Weaver@nectech.com Subject: re: looking for best winsock stack out there To: winsock-hackers@sunsite.unc.edu Cc: I am on vacation until 10/18. Please contact Dick Dingler in an emergency. ------------- Original Text >From gloster@inference.com (Vance M. Gloster), on 10-08-93 6:36: Which is the most reliable Winsock stack out there? We're developing with one stack which has a couple of bugs, and would like to find out which manufacturer has the most stable bugfree implementation. Thanks in advance, I have found the Windows NT WinSock stack and development environment to be MUCH better than any Windows 3.1-based environment. I never had to reboot even once! The worst was when I got it really fouled up and the stack (or possibly the server I was testing with) took about 4 minutes to reset itself. -Vance Gloster gloster@inference.com From James=L.=Weaver@nectech.com Fri Oct 8 09:48:42 1993 Received: from nectech.com (milkyway.nectech.com) by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA25364; Fri, 8 Oct 93 09:48:42 EDT Received: from CS011.nectech.com by nectech.com with SMTP (5.65/29-nectech) id AA00855; Fri, 8 Oct 93 09:33:12 -0400 Return-Path: Message-Id: <9310081333.AA00855@nectech.com> Received: by CS011.nectech.com with VINES ; Fri, 8 Oct 93 09:41:22 EDT Date: Fri, 8 Oct 93 09:41:18 EDT From: James=L.=Weaver@nectech.com Subject: re: looking for best winsock stack out there To: winsock-hackers@sunsite.unc.edu Cc: I am on vacation until 10/18. Please contact Dick Dingler in an emergency. ------------- Original Text >From James=L.=Weaver@nectech.com, on 10-08-93 8:30: I am on vacation until 10/18. Please contact Dick Dingler in an emergency. ------------- Original Text >From gloster@inference.com (Vance M. Gloster), on 10-08-93 6:36: Which is the most reliable Winsock stack out there? We're developing with one stack which has a couple of bugs, and would like to find out which manufacturer has the most stable bugfree implementation. Thanks in advance, I have found the Windows NT WinSock stack and development environment to be MUCH better than any Windows 3.1-based environment. I never had to reboot even once! The worst was when I got it really fouled up and the stack (or possibly the server I was testing with) took about 4 minutes to reset itself. -Vance Gloster gloster@inference.com From wilson@ftp.com Sat Oct 9 14:22:35 1993 Received: from ftp.com (babyoil.ftp.com) by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA23607; Sat, 9 Oct 93 14:22:35 EDT Received: from wilson.zaphod.ftp.com by ftp.com via PCMAIL with DMSP id AA19735; Sat, 9 Oct 93 14:22:46 -0400 Date: Sat, 9 Oct 93 14:22:46 -0400 Message-Id: <9310091822.AA19735@ftp.com> To: winsock-hackers@sunsite.unc.edu Subject: FD_CLOSE -- confusing? From: wilson@ftp.com (Brad Wilson) Reply-To: wilson@ftp.com Sender: wilson@ftp.com Repository: babyoil.ftp.com Originating-Client: zaphod.ftp.com I've had two people ask me in the last week about the correct use of FD_CLOSE. The docs seems to indicate -- because I know TCP -- that the FD_CLOSE comes when the remote side closes it's sending side of the socket. This brings up multiple points: o Is FD_CLOSE posted immediately upon the receipt of the remote FIN, or once all the data has been read from the receive buffer? (ie, once you get an FD_CLOSE, have you read all the data or is there possible data to read yet?) o Can you write to a socket once you get an FD_CLOSE? When does the socket become unavailable? At closesocket() call? Are you required to call closesocket() on the socket? The way I understood it, FD_CLOSE means that the remote side is done sending. Are vendors postponing the FD_CLOSE notification until all data has been read from the buffer? Second point, what's the meaning of shutdown(s,0) ? Why would a stack want to buffer incoming data if it isn't going to be read? And why would anyone want this? Can't they just not read the data? Since there's no way in TCP to ask the other side to shut their side down, why is this function present? (Another protocol that I don't know about for future use?) Thanks... -- Brad Wilson "I think the most important thing to note is that in #include America, those on the right can do what those on the #include left can only talk about." - Richard M. Nixon From paul@atlas.dev.abccomp.oz.au Thu Oct 14 01:46:37 1993 Received: from usage.csd.unsw.OZ.AU by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA06257; Thu, 14 Oct 93 01:46:37 EDT Received: by usage.csd.unsw.OZ.AU id AA06834 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Thu, 14 Oct 1993 15:46:59 +1000 Received: by atlas (4.1/1.35) id AA28584; Thu, 14 Oct 93 15:55:44 EST Message-Id: <9310140555.AA28584@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 14 Oct 1993 15:55:43 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: Correct format for ?_aliases in database structs? Could someone please clarify the correct way of constructing the various database structures (struct hostent, etc), particularly the ' char FAR * FAR * h_aliases ' and similar fields when they have no members? Can h_aliases be NULL, or should it be non-NULL pointing to a NULL pointer ? I've been making h_aliases NULL, but this breaks a couple of applications, including WSAT. Is this illegal, or is no-one checking for this case? -- 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 wilson@ftp.com Sun Oct 17 17:12:20 1993 Received: from ftp.com (babyoil.ftp.com) by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA08629; Sun, 17 Oct 93 17:12:20 EDT Received: from wilson.greatest.ftp.com by ftp.com via PCMAIL with DMSP id AA07705; Sun, 17 Oct 93 17:12:29 -0400 Date: Sun, 17 Oct 93 17:12:29 -0400 Message-Id: <9310172112.AA07705@ftp.com> To: iblenke@x102a.ess.harris.com Subject: Re: FD_CLOSE message: When does it get sent? From: wilson@ftp.com (Brad Wilson) Reply-To: wilson@ftp.com Cc: winsock-hackers@sunsite.unc.edu Sender: wilson@ftp.com Repository: babyoil.ftp.com Originating-Client: greatest.ftp.com I Cc'ed this back onto the newsgroup ... actually, into -hackers. >> Yikes! FD_CLOSE is still in the queue! You read ahead! ;-) >> Two things happened here: (1) An FD_READ yielded the 0 return from >> recv() which means close. You closed. As such ... (2) you get an >> FD_CLOSE on a socket that is no longer existant! Neat, huh? ;-) >> >> Receiving an FD_CLOSE after you closesocket() is a possibility then?!? >> Am I glad I ignore the return code from closesocket() *ducking real quick* Even more realistic ... what happens when the socket that's been closed has been re-used because the amount of time has been "non-trivial"? Then you're actually trying to close a socket that DOES exist ... just not YOUR socket. Suggested workaround: o On FD_READ, recv(); if you get a zero, assume that's the end of data, but _don't_close_the_socket_. o On FD_CLOSE, recv() until you get the zero, then close the socket. Make sure you get both messages (FD_READ and FD_CLOSE) for this to work correctly. (That seems better than ducking, right? ;-) -- Brad Wilson Share and Enjoy! Voice: (508) 685-4000, (800) 282-4FTP Not speaking for FTP Software, Inc. Fax: (508) 659-6297, (508) 794-4477 "It must be Thursday ... I could never get the hang of Thursdays."