From alun@internet.wst.com Thu Apr 3 02:49:00 1994 Received: from internet.wst.com.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12995; Thu, 31 Mar 1994 09:47:42 -0500 Received: by internet.wst.com.wst.com (4.1/SMI-4.1) id AA00735; Thu, 31 Mar 94 08:49:01 CST From: alun@internet.wst.com (Alun Jones) Message-Id: <9403311449.AA00735@internet.wst.com.wst.com> Subject: Re: What does send() returning 0 mean ? revisited To: paul@atlas.abccomp.oz.au Date: Thu, 31 Mar 94 8:49:00 CST Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9403310450.AA25514@atlas>; from "paul@atlas.abccomp.oz.au" at Mar 31, 94 8:54 am X-Mailer: ELM [version 2.3 PL11] > I'd like to conduct a straw-poll please, on the expected behaviour > of calling send() with a zero length - this seems to be one > case that different stacks handle quite differently, and there is currently > no guidance in the specification. I would ask what the expected use of a send() call with zero length would be - is it just a device so that a programmer doesn't have to surround his send() calls with an if statement to check that the number of bytes is not zero? If this is the only advantage of this approach, then I would advocate not allowing 0 as a number of bytes to send. > My thoughts are that this is a perfectly valid, though not > particularly useful, thing to do, and that this is the only time it > is valid for send() to return 0 - which indicates success, 'cause the > number of bytes able to be written == number of bytes requested. > Other stacks seem to call this an error, and Trumpet Winsock returns > SOCKET_ERROR with error code WSAEINVAL (Invalid Argument) [ although the > Error Codes section for send() indicates WSAEINVAL means "The socket > has not been bound with bind()"] Being strictly pedantic, the documentation says that (on a non-blocking SOCK_STREAM socket, at least) the return value will be between 1 and the number of bytes requested, or the error condition. "Between" is one issue here - mathematically, I guess this could mean "between 1 and 0" if the number of bytes requested is 0, but a more English oriented reading implies that the number of bytes requested would be more than (or equal to) 1. I believe that returning 0 if the number of bytes requested is greater than 0 is a BAD THING, since that means that no data could be sent, or stored for sending, which really means WSAEWOULDBLOCK (on non-blocking sockets). Obviously, a blocking socket won't return anything until all of the bytes have been sent, or an error has occurred, so a blocking socket should either return an error condition, or the number you requested. (Note that if you want to send a two/more part message out on a blocking port, and want to use the number returned from send() to determine where any error occurred, and which messages made it through, you should probably be looking at calling send() once for each message instead, or going to non-blocking sockets). The only use I can see for _passing_ 0 bytes in to the send() function is to tell if all previous (non-blocking) sends have been sent through the transport layer, by setting the socket to blocking, and sending 0 bytes. A stack might then decide to block until all buffered output has been sent. This is not described in the documentation, however, and would require either stack dependency (a BAD THING), or a new standard (a GOOD THING). However, the approach of winsock seems to be that the application developer should not need to know when data has been sent through the transport, so even this would be a rather dubious functionality to ask for. > Comments from others, both stack developers and application > developers, please .... As background, I am an application developer - I wrote cooksock and wftpd. Wftpd seems to break quite a few stacks, since I tend to be somewhat pedantic about the things I expect from compliant stacks. I'm hoping that winsock stack developers have as open minded an approach to making their stacks more usable to winsock application developers, as they had to implementing the spec in the first place. I know that FTP Software are continually improving their software to make it more useful to other winsock developers, and I'd like to see similar approaches from the other winsock stack developers. My other pet(ty) gripe is that there is (apparently) no freely available documentation about differences between various implementations of winsock. When a user calls me and says "I can't get your program working on stack x", it would be nice to be able to search through a list of that vendor's differences from the winsock spec, and from other vendors - things like DNS compatibility, what kind of error values are returned, which functions aren't yet written, what assumptions had to be made that weren't covered in the spec - that sort of thing. I would suggest that a "docs" area on sunsite might be a good place to store such information if it existed, but since sunsite isn't my site, I can't expect that such a thing would happen. I'd offer this site, but we have a 14400 baud modem connecting us to the rest of the world, so I don't think that would be a great idea! Alun. From rcq@mailserv-D.ftp.com Thu Apr 3 04:47:47 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13125; Thu, 31 Mar 1994 09:48:35 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 31 Mar 1994 09:48:34 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA11710; Thu, 31 Mar 94 09:47:47 EST Date: Thu, 31 Mar 94 09:47:47 EST Message-Id: <9403311447.AA11710@mailserv-D.ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: What does send() returning 0 mean ? revisited 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 Thu Mar 31 09:47:34 1994] Originating-Client: oysters.ftp.com Content-Length: 1519 > I'd like to conduct a straw-poll please, on the expected behaviour > of calling send() with a zero length - this seems to be one > case that different stacks handle quite differently, and there is currently > no guidance in the specification. > > My thoughts are that this is a perfectly valid, though not > particularly useful, thing to do, and that this is the only time it > is valid for send() to return 0 - which indicates success, 'cause the > number of bytes able to be written == number of bytes requested. > Other stacks seem to call this an error, and Trumpet Winsock returns > SOCKET_ERROR with error code WSAEINVAL (Invalid Argument) [ although the > Error Codes section for send() indicates WSAEINVAL means "The socket > has not been bound with bind()"] > > Comments from others, both stack developers and application > developers, please .... Since there is no obvious reason to reject a length of zero (it's not a useful request, but it's not a harmful one), we return 0. We did this partly because the spec is not clear on the issue, but also because we try to work on the philosophy that a function should not fail without good reason. Since there are unforeseen conditions under which an application can sometimes mistakenly try to send 0 bytes, there's no reason for the DLL to punish them for it. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From alun@internet.wst.com Thu Apr 3 03:00:12 1994 Received: from internet.wst.com.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA14695; Thu, 31 Mar 1994 09:58:27 -0500 Received: by internet.wst.com.wst.com (4.1/SMI-4.1) id AA00773; Thu, 31 Mar 94 09:00:13 CST From: alun@internet.wst.com (Alun Jones) Message-Id: <9403311500.AA00773@internet.wst.com.wst.com> Subject: Re: Closing and reusing sockets To: paul@atlas.abccomp.oz.au Date: Thu, 31 Mar 94 9:00:12 CST Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9403310353.AA25427@atlas>; from "paul@atlas.abccomp.oz.au" at Mar 31, 94 9:11 am X-Mailer: ELM [version 2.3 PL11] After much talk on issues of bind() and connect() and listen() and sockets whose address is already in use, Paul Brooks added: > To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed > before you can connect _from_the_same_port_number_ to the same remote > machine listening on the _same_remote_port_ - possibly by blocking in > a lingering close, or using linger to hard-close the connection when > you're done the first time. Please note that if you're writing a server, you are most likely listening for any machine, which is a special remote machine address, and quite obviously you will not be able to listen for any machine on that same port until the previous server's job has totally finished. Alun. ~~~~ From alun@internet.wst.com Thu Apr 3 03:07:28 1994 Received: from internet.wst.com.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15965; Thu, 31 Mar 1994 10:04:18 -0500 Received: by internet.wst.com.wst.com (4.1/SMI-4.1) id AA00810; Thu, 31 Mar 94 09:07:29 CST From: alun@internet.wst.com (Alun Jones) Message-Id: <9403311507.AA00810@internet.wst.com.wst.com> Subject: Winsock on top of DOS stacks. To: winsock-hackers@sunsite.unc.edu Date: Thu, 31 Mar 94 9:07:28 CST X-Mailer: ELM [version 2.3 PL11] Here's an interesting problem - I have my WSACleanup code called in the OnDestroy part of my CWinApp (you can tell which compiler I'm using, right?), and it doesn't seem to get called in the situation of the Windows system being closed. Now this is obviously a bug in my program, but it causes an interesting problem that might bear investigating. If Windows exits unexpectedly, and yet the DOS subsystem is still running, and if the underlying TCP/IP stack is a DOS-based system (and still running), should all connected/listening sockets be closed? Under at least one implementation, for instance, when going back into windows, my ftp daemon won't start, because (it claims) the ftp port is being listened on by some other process (presumably my previous instance under windows). If Windows exits cleanly, but applications haven't called WSACleanup, or closed all their sockets, should the TCP/IP stack underneath be responsible for noting that there is no process connected with those sockets, and close them itself? I'm not (yet) arguing one way or the other - just soliciting comments as to how this might be achieved - whether it's reasonably easy or not, and whether it's something that might be put into the standard. And on an unrelated note, I seem to remember somebody mentioning a Winsock-a-thon session coming up soon at Microsoft - is anyone going to be testing some of the shareware programs there, too? (esp. mine! :) Alun. ~~~~ From rcq@mailserv-D.ftp.com Fri Apr 1 19:39:35 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA26905; Sat, 2 Apr 1994 01:03:30 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 2 Apr 1994 00:40:26 -0500 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02833; Sat, 2 Apr 94 00:39:35 EST Date: Sat, 2 Apr 94 00:39:35 EST Message-Id: <9404020539.AA02833@mailserv-D.ftp.com> To: alun@internet.wst.com Subject: Re: Winsock on top of DOS stacks. 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 Sat Apr 2 00:39:24 1994] Originating-Client: hurricane.ftp.com Content-Length: 1826 > If Windows exits cleanly, but applications haven't called WSACleanup, > or closed all their sockets, should the TCP/IP stack underneath be > responsible for noting that there is no process connected with those > sockets, and close them itself? A better way to phrase the question is in terms of tasks, I think. You could ask: "should sockets persist after their tasks are ended?" To this, I'd answer no. Orphaned sockets should be closed by the stack/DLL. I know that our current WinSock DLL can leave orphan sockets under some circumstances after an application has ended. I've seen this happen with our DLL if the application GPF's (so Windows doesn't call the Windows Exit Procedure: WEP() to unload our DLL), or if an application doesn't call WSACleanup() *AND* there's another WinSock application execution (so the DLL stays memory resident). Doing the "garbage collection" to reclaim orphaned sockets after these scenarios is definately something high on the list of things that we plan to address. > And on an unrelated note, I seem to remember somebody mentioning a > Winsock-a-thon session coming up soon at Microsoft - is anyone going > to be testing some of the shareware programs there, too? (esp. mine! Considering that there're only two days to test what will likely be a large matrix of applications and WinSock implementations, it is not likely anyone will be testing anything that doesn't have a body representing it. But on the bright side, you can be sure I'll bring your FTP Daemon and the plethora of other public domain applications along for the ride. Proven applications like these are always handy for benchmarks, if nothing else! Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From carlp@onpmomma.isc-br.com Fri Apr 1 23:36:33 1994 Received: from onpmomma.isc-br.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA09918; Sat, 2 Apr 1994 10:37:41 -0500 Received: by onpmomma.isc-br.com (Smail3.1.28.1 #3) id m0pn7kP-000A9lC; Sat, 2 Apr 94 07:36 PST Message-Id: Subject: Re: What does send() returning 0 mean ? revisited To: rcq@ftp.com Date: Sat, 2 Apr 94 7:36:33 PST From: Carl Paukstis Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9403311447.AA11710@mailserv-D.ftp.com>; from "Bob Quinn" at Apr 1, 94 8:32 pm X-Mailer: ELM [version 2.3 PL11] Bob Quinn writes: > >Since there is no obvious reason to reject a length of zero (it's >not a useful request, but it's not a harmful one), we return 0. >should not fail without good reason. Since there are unforeseen >conditions under which an application can sometimes mistakenly >try to send 0 bytes, there's no reason for the DLL to punish >them for it. Right answer, Bob! -- Carl Paukstis, RRR&RSG DoD#0432 1KQSPI=8.80 carlp@mail.spk.olivetti.com Olivetti North America carlp@mom.isc-br.com (Oli North): will deny responsibility voice: (509) 927-5439 0700-1600 M-F Spokane, Washington, USA FAX: (509) 927-2499 24 hrs. From paul@atlas.dev.abccomp.oz.au Tue Apr 5 11:18:55 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA29470; Tue, 5 Apr 1994 02:05:55 -0400 Received: by usage.csd.unsw.OZ.AU id AA13525 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 5 Apr 1994 16:05:58 +1000 Received: by atlas (4.1/1.35) id AA09083; Tue, 5 Apr 94 16:18:56 EST Message-Id: <9404050618.AA09083@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 5 Apr 1994 16:18:55 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: alun@internet.wst.com, Multiple recipients of list Subject: Re: Winsock on top of DOS stacks. Thus expounded Alun Jones on Apr 1,10:50pm: /-------------------- |If Windows exits unexpectedly, and yet the DOS subsystem is still |running, and if the underlying TCP/IP stack is a DOS-based system (and |still running), should all connected/listening sockets be closed? |Under at least one implementation, for instance, when going back into |windows, my ftp daemon won't start, because (it claims) the ftp port |is being listened on by some other process (presumably my previous |instance under windows). I would have thought the DLL, if at all possible, should keep track of sockets owned by a given application, and clean them up if the application exits. A DLL has a routine called when the DLL itself is unloaded (i.e. when the last application using WINSOCK exits) which can be used to perform this cleanup. Of course, if Windows crashes out so this routine is never called, then the DOS subsystem has no way of knowing there is no longer an application to own the sockets. And if there was a socket with a WSAAsyncSelect active, in all likelyhood the next callback will crash DOS as well. If by 'exist unexpectedly' you mean Windows crashing out to the DOS prompt without exiting cleanly, then it would be unlikely that the DOS system will cleanly close the sockets for you. If Windows exits cleanly, then yes, the DLL should close all outstanding sockets before it exits. -- 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 bryan%alex.com@gateway.alex.com Tue Apr 5 06:20:43 1994 Received: from post.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA21145; Tue, 5 Apr 1994 06:20:43 -0400 Received: from gateway.alex.com by post.demon.co.uk id aa05038; 5 Apr 94 11:17 GMT-60:00 Return-Path: Received: from SKID by woody.alex.com (4.1/SMI-4.1) id AA28610; Tue, 5 Apr 94 11:01:27 BST Date: Tue, 5 Apr 94 11:01:27 BST Message-Id: <9404051001.AA28610@woody.alex.com> X-Sender: bryan@alex.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: winsock-hackers@sunsite.unc.edu From: Bryan Boreham Subject: Re: Closing and reusing sockets X-Mailer: > From: paul@atlas.abccomp.oz.au > [loads of stuff -- should one call bind?] > Now, the twist from your last sentence (above) is that you want to > bind() and connect() from a free reserved port - only in this case is > ---- ======== ---- > it necessary or recommended to call bind() before connect(). Thanks for this confirmation. > To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed > before you can connect _from_the_same_port_number_ to the same remote > machine listening on the _same_remote_port_ - possibly by blocking in > a lingering close, or using linger to hard-close the connection when > you're done the first time. This is roughly what I said in the very first message in this thread -- hard-closing the socket makes the problem go away. I guess that waiting for the close to complete (probably not actually blocking, given that we're all nice cooperative Windows programmers) is gentler, but it would complicate the exit logic of the program rather a lot. This would all be a lot easier if we could rely on bind() giving EADDRINUSE so that the next port could be used instead, and leave the stack to get on with closing down the old one quietly. Bryan. From paul@atlas.dev.abccomp.oz.au Wed Apr 6 05:37:08 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA26406; Tue, 5 Apr 1994 20:24:57 -0400 Received: by usage.csd.unsw.OZ.AU id AA22673 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 6 Apr 1994 10:24:07 +1000 Received: by atlas (4.1/1.35) id AA11109; Wed, 6 Apr 94 10:37:09 EST Message-Id: <9404060037.AA11109@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 6 Apr 1994 10:37:08 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: bryan@alex.com, Multiple recipients of list Subject: Re: Closing and reusing sockets Thus expounded Bryan Boreham on Apr 5, 9:26am: /-------------------- |> From: paul@atlas.abccomp.oz.au | |> To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed |> before you can connect _from_the_same_port_number_ to the same remote |> machine listening on the _same_remote_port_ - possibly by blocking in |> a lingering close, or using linger to hard-close the connection when |> you're done the first time. | |This is roughly what I said in the very first message in this thread -- |hard-closing |the socket makes the problem go away. I guess that waiting for the close to |complete (probably not actually blocking, given that we're all nice cooperative |Windows programmers) is gentler, but it would complicate the exit logic of the |program rather a lot. | |This would all be a lot easier if we could rely on bind() giving EADDRINUSE |so that the next port could be used instead, and leave the stack to |get on with closing down the old one quietly. True, but you still have to think about the case where your local machine has closed the socket down OK, allowing you to BIND to the same port number in the future, but the REMOTE end still has the same port/address association valid, probably in TIMEWAIT state for two minutes. In this case, your bind() will succeed, but the remote end may well refuse the connection. WSAEADDRINUSE is a valid return from connect(), as well as bind(). Also, if you set the socket option SO_REUSEADDR you will be allowed to bind() to the same port number, on the assumption that you want to connect to a different host/port from last time. If you try to connect() to the same host/port as last time, you'll get back WSAEADDRINUSE from connect(). Maybe if you describe what you are actually trying to do to the list, instead of vague references to a private exchange, we might be able to help you. -- 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 stcheng@ee.tamu.edu Tue Apr 5 16:33:01 1994 Received: from EE.TAMU.EDU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11603; Tue, 5 Apr 1994 22:31:34 -0400 Received: by ee.tamu.edu (5.61/1.34) id AA13007; Tue, 5 Apr 94 21:33:02 -0500 From: stcheng@ee.tamu.edu (Franklin S. Cheng) Message-Id: <9404060233.AA13007@ee.tamu.edu> Subject: setoptsock() To: winsock-hackers@sunsite.unc.edu (WINSOCK) Date: Tue, 5 Apr 1994 21:33:01 -0500 (CDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 765 Fellow hackers, setoptsock() allows socket programmers to modify the socket options, like the buffer size for sending and receiving.(using level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF) My question is when the _receiving_ buffer size is bigger than one UDP packet, say 5 times. Will the incoming 5 packets be held in the buffer if the app doesn't read it ? Or no matter how big the buffer size is, it always holds just one UDP packet and discard the subsequence UDP packets if the apps doesn't read it ? What about if the buffer size is 5.3 times of the size of the incoming UDP packets , would the 6th one be stuffed into the remaining buffer size -- .3 of the UDP packet ? And how about the _sending_ buffer for this case ? thanks, Franklin. From ICH211@ZAM001.ZAM.KFA-JUELICH.DE Wed Apr 6 13:24:53 1994 Received: from zam001.zam.kfa-juelich.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19461; Wed, 6 Apr 1994 05:40:24 -0400 Message-Id: <199404060940.AA19461@SunSITE.Unc.EDU> Received: from DJUKFA11 by ZAM001.ZAM.KFA-JUELICH.DE (IBM VM SMTP V2R2) with BSMTP id 2542; Wed, 06 Apr 94 11:40:25 +0200 Date: Wed, 06 Apr 94 11:24:53 +0200 From: Thomas Heil Organization: Forschungszentrum Juelich GmbH - Institut fuer Chemie 2 Subject: Re: Closing and reusing sockets To: Multiple recipients of list In-Reply-To: Message of Tue, 5 Apr 1994 09:13:03 -0400 from On Tue, 5 Apr 1994 09:13:03 -0400 you said: >> From: paul@atlas.abccomp.oz.au > >> [loads of stuff -- should one call bind?] > >> Now, the twist from your last sentence (above) is that you want to >> bind() and connect() from a free reserved port - only in this case is >> ---- ======== ---- >> it necessary or recommended to call bind() before connect(). > >Thanks for this confirmation. > >> To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed >> before you can connect _from_the_same_port_number_ to the same remote >> machine listening on the _same_remote_port_ - possibly by blocking in >> a lingering close, or using linger to hard-close the connection when >> you're done the first time. > >This is roughly what I said in the very first message in this thread -- >hard-closing >the socket makes the problem go away. I guess that waiting for the close to >complete (probably not actually blocking, given that we're all nice cooperative >Windows programmers) is gentler, but it would complicate the exit logic of the >program rather a lot. > >This would all be a lot easier if we could rely on bind() giving EADDRINUSE >so that the next port could be used instead, and leave the stack to >get on with closing down the old one quietly. > >Bryan. > I had the same problem with unreliable bind()s (with FTP Software's Winsock) in my WLPR.DLL which is used by my LPR client and Windows Spooler. The LPR protocol demands the client to bind to a free reserved port number, So I took the sample code from the WinSock specs. The bind() always succeeded, and the connect() bombed with EADDRINUSE when there was an older connection lingering. So I put a linger(1,0) before the closesocket() call. This forced the connections to close completely, but it had the nasty side effect to give the LPR server a "connection reset" error, which caused a lot of LPDs to die (meaning the spool job went into the queue but was not sent to the printer). I got the same reply from FTP Software about "no bind used internally" etc, which I actually don't find acceptable. I believe that sample code in a specification should work with all compliant implementations, otherwise the implementation is *not* specification compliant. Since the FTP Winsock.DLL surely has access to all pending connection info it should be able to determine at bind() time if there is a local address in use, and return EADDRINUSE if necessary. What I had to do in my code is to have the bind() loop followed by a connect() as it should be, and have another loop around all this to try a new port if the connect() fails. Just my 2 cents ... /Thomas ---------------------------------------+-------------------------------------- Mail: Thomas Heil | EMail: BITNET: ICH211@DJUKFA11.BITNET Forschungszentrum Juelich - ICG2 | Internet: th.heil@kfa-juelich.de 52425 Juelich | Phone: +49 2461 61-6915 Germany | Fax: +49 2461 61-5346 From bryan%alex.com@gateway.alex.com Wed Apr 6 07:56:40 1994 Received: from post.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01736; Wed, 6 Apr 1994 07:56:40 -0400 Received: from gateway.alex.com by post.demon.co.uk id ab18202; 6 Apr 94 12:21 GMT-60:00 Return-Path: Received: from SKID by woody.alex.com (4.1/SMI-4.1) id AA15772; Wed, 6 Apr 94 12:21:39 BST Date: Wed, 6 Apr 94 12:21:39 BST Message-Id: <9404061121.AA15772@woody.alex.com> X-Sender: bryan@alex.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: winsock-hackers@sunsite.unc.edu From: Bryan Boreham Subject: Re: Closing and reusing sockets X-Mailer: >From Paul Brooks, paul@abccomp.oz.au: >True, but you still have to think about the case where your local machine >has closed the socket down OK, allowing you to BIND to the same >port number in the future, but the REMOTE end still has the same >port/address association valid, probably in TIMEWAIT state for two minutes. > >In this case, your bind() will succeed, but the remote end may well refuse >the connection. WSAEADDRINUSE is a valid return from connect(), Aha! I was working on the assumption that EADDRINUSE referred to the *local* address, not the remote address. The spec doesn't specify -- is there any other explicit reference? I see that Stevens "Unix Network Programming" does use it as you describe in the rcmd example, page 570. However, exactly the same circumstances didn't result in a failure at all using the Trumpet stack. I think I'll do some network sniffing to see if I can spot what is different. >as well as bind(). Also, if you set the socket option SO_REUSEADDR you will >be allowed to bind() to the same port number, on the assumption that you want >to connect to a different host/port from last time. If you try to connect() >to the same host/port as last time, you'll get back WSAEADDRINUSE from >connect(). This is not what we are doing. >Maybe if you describe what you are actually trying to do to the list, I gave a description in the first instance, but it was perhaps not very precise. The trouble is that we sell a development system, a programming language, and therefore I have to cover all the cases that can arise when third parties use our language to write systems. I am not asking for specific answers to work round one program failure, I am asking about how stacks should behave *in* that failure mode. Here is one specifc case: suppose a program uses rsh twice in succession, something which is very easy in the Alex language. We must bind to a free reserved port locally, and we must connect to the same remote port each time. We would like to do this reliably on any of the dozen or more Winsock stacks that our customers might use, with the minimum of hack work-arounds that "just happen to fix it". >instead of vague references to a private exchange, I believe I quoted verbatim all references to the private exchange. >we might be able to help you. It all helps. Thank you. Bryan. From cornell@syl.dl.nec.com Wed Apr 6 10:13:08 1994 Received: from telemann.inoc.dl.nec.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08027; Wed, 6 Apr 1994 16:13:29 -0400 Received: by telemann.inoc.dl.nec.com (4.1/YDL1.9-920831.09) id AA25392(telemann.inoc.dl.nec.com); Wed, 6 Apr 94 15:13:14 CDT Received: by texas.syl.dl.nec.com (8.6.4/YDL1.9-930614.17) id PAA28068(texas.syl.dl.nec.com); Wed, 6 Apr 1994 15:13:12 -0500 Received: by michigan.syl.dl.nec.com (4.1/YDL1.9-920708.13) id AA08128(michigan.syl.dl.nec.com); Wed, 6 Apr 94 15:13:09 CDT From: cornell@syl.dl.nec.com (Cornell Kinderknecht) Message-Id: <9404062013.AA08128@michigan.syl.dl.nec.com> Subject: PC SOCKS Pack - PC Winsock clients behind firewall To: winsock-hackers@sunsite.unc.edu Date: Wed, 6 Apr 1994 15:13:08 -0500 (CDT) Cc: ylee@syl.dl.nec.com (Ying-Da Lee), cornell@syl.dl.nec.com (Cornell Kinderknecht) X-Mailer: ELM [version 2.4 PL23beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9532 Announcing the availability of the "PC SOCKS Pack" Version 1.01... The "PC SOCKS Pack" is a collection of Windows network applications that are Winsock 1.1 compliant that have been modified to be SOCKS compliant. They can be run on PCs sitting behind a firewall that have access to a SOCKS 4.0 or above server. The "PC SOCKS Pack" is intended to be dynamic--adding more SOCKSified PC network applications as they become available. Right now it's pretty small and only contains three clients which I've converted. We'd be happy to convert more Winsock compliant applications if source is made available (hint hint). The applications are: FTP-s: This is very nice and is based on John A. Jounod's WS_FTP version 93.12.05. Works pretty slick. FINGER-s: This is based on Lee Murach's Finger 3.1. Pretty self-explanatory and easy to use. TELNET-s: This is real clunky (the SOCKS stuff works great however) and has some bugs. It seems to work OK for most sites that I've tried to connect to but it's not too graceful about timed out connections and other out of the ordinary things. It's based on the NCSA unsupported beta 3 Wintel. Anyone want to offer some nice, well-behaved Telnet source to be converted over to SOCKS?????? You can get the "PC SOCKS Pack" via anonymous ftp from: ftp.nec.com in the directory /pub/security/socks.cstc/PC_Socks_Pack Grab the FILES file to see what's in there. All clients are archived into one zip file. NOTE: The zip files extract into multiple subdirectories so be sure to supply the -d option to PKUNZIP. The top directory of the release has information and detailed instructions for configuring the PC for SOCKS and each subdirectory has a SOCKSified application. Questions and comments about the "PC SOCKS Pack" in general and the SOCKS part of the individual applications can be directed to me. I'm not much help with the original applications although I can probably look at obvious bugs. I've left the user interface and workings of the original applications pretty much untouched from the original. Again, we're looking for source to other Winsock network applications to convert over!! At the end of this message, I'll include the README file from the "PC SOCKS Pack" followed by a blurb describing SOCKS itself for those unfamiliar with it. --- Cornell | Cornell Kinderknecht Email: cornell@syl.dl.nec.com | | CSTC/CNAD | | NEC Systems Lab./NEC USA Phone: 214-518-3509 | | Irving, TX (Dallas) Fax: 214-518-3552 | >>>>>>>>>> Start README file <<<<<<<<<<<< ============================ PC SOCKS Pack - Version 1.01 ============================ File: README Welcome to the PC SOCKS Pack. This is a collection of Windows Sockets client applications that can be used from a PC sitting behind a network firewall that has direct access to a proxy SOCKS server running version 4.0 or above to reach hosts outside the firewall. Presently, there are many packages available in the UNIX environment that are SOCKS compliant and there seems to be a similar need in the PC environment. Currently, there are three applications included in the pack that I've converted (SOCKSified) from other packages found on the net in source form. I hope to add more to the collection. Can anyone point me to the source for other packages? I'd like to find source for a Windows Gopher client real fast. The applications: FINGER-s: A finger application based on Lee Murach's Finger3.1. WINTEL-s: A telnet application based on NCSA's unsupported beta 3 telnet. This application is a bit buggy. WS_FTP-s: An ftp client based on John A. Junod's WS_FTP version 93.12.05. ------------------- 1.0 Where to get it ------------------- If you're reading this file, chances are you already know where to get it but just in case... The PC SOCKS Pack can be downloaded via anonymous ftp from: ftp.nec.com in the directory: /pub/security/socks.cstc/PC_Socks_Pack Get the file "FILES" from that directory to see a description of what's in the directory and what files you need to download. ---------------------- 2.0 About this release ---------------------- The PC SOCKS Pack is distributed as a single ZIP file which extracts into multiple directories (remember to use the -d option for PKUNZIP). The top directory contains general information about the package and instructions for configuring SOCKS on your system. Each subdirectory contains an individual SOCKSified application with specific installation instructions for the application along with files from that package's original release. The SOCKSification of each package only adds the capability to connect to outside networks through a SOCKS server. The original user interface and operation of each package have not been changed from the original author's package. I should mention that if you do not need the SOCKS capabilities, you can still use the applications in this package by setting the SOCKS configuration on your machine so that all connections are direct. However, it's probably best to use the original un-modified applications if you don't need SOCKS. In most cases, I've included a copy of the original executable for convenience and testing purposes. --------------------- 3.0 Priliminary steps --------------------- To see a description of all the files in this distribution, see the "FILES" file in the top directory of this distribution. If you need to know more about SOCKS itself, see the file "WHATSOCK" in the top directory of this distribution. There are some system and software requirements that you must meet in order to use the PC SOCKS Pack. It is important that you read the file "REQUIRES" and verify that all the requirements are met for your system and network. Please read and understand the individual copyrights and permissions for each package. In the top directory, there is a file called "COPYRGHT" that contains the notices and copyrights from all of the applications included in this distribution. See the file "ACKNLGMT" to see the credits for each application. To see what system and software setups that this software has been tested on, see the file "SYSTEMS". I'd like to add your system and software setups to the list if you'd like to email me the information. ------------------- 4.0 Getting started ------------------- To start installing the PC SOCKS Pack, please refer to the file "INSTALL" in the top directory of this distribution. ---------------------- 5.0 SOCKS Mailing List ---------------------- There is a mailing list for SOCKS maintained by the C&C Software Technology Center at NEC Systems Lab. It's primarly a technical discussion group concerning the ongoing development and nurturing of the SOCKS protocol and related software. To join the SOCKS mailing list, send email to: majordomo@syl.dl.nec.com with subscribe socks your@email.address as the first line of the message body. ------------------------- 6.0 PC SOCKS Pack Contact ------------------------- The PC SOCKS Pack was organized and the applications in it were converted for SOCKS compliance by: Cornell Kinderknecht C&C Software Technology Center (CSTC) NEC Systems Laboratory Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies, and that the name of NEC Systems Laboratory not be used in advertising or publicity pertaining to distribution of the document or software without specific, written prior permission. THE SOFTWARE IS PROVIDED ``AS IS'' AND NEC SYSTEMS LABORATORY DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL NEC SYSTEMS LABORATORY BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >>>>>>>>>> Start What_Is_SOCKS.CSTC <<<<<<<<<< What Is SOCKS.CSTC SOCKS belongs to the type generally referred to as proxy servers. Usually when a network firewall is set up to protect hosts inside an organization from attacks that may come from outside through the network, these inside hosts lose their IP-accessibility with the outside world and thus can no longer use things like telnet, ftp, gopher, WWW, etc. to access the vast resources available in the Internet. Proxy servers with their clients restore these functions to the hosts inside the firewall without breaching their security requirements. The original SOCKS was written by David Koblas . The CSTC releases have been mainly the results of work by Ying-Da Lee of C&C Software Technology Center (CSTC), NEC Systems Laboratory, with contributions by many others throughout the world. The current CSTC release is version 4.1. It is known to run on SunOS 4.1.x, Irix 4.0.x, Ultrix 4.3, HP-UX 9.0x, AIX 3.2.x, Interactive Systems Unix, Alpha OSF 1.3, Solaris 2.2, NetBSD 0.9, UnixWare, and Linux 0.99pl13. The SOCKS.CSTC release can be found via anonymous ftp to ftp.nec.com in the directory /pub/security/socks.cstc. The file "FILES" in that directory describes what is contained there. From paul@atlas.dev.abccomp.oz.au Fri Apr 8 05:21:46 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03216; Thu, 7 Apr 1994 20:08:28 -0400 Received: by usage.csd.unsw.OZ.AU id AA05255 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Fri, 8 Apr 1994 10:08:46 +1000 Received: by atlas (4.1/1.35) id AA23171; Fri, 8 Apr 94 10:21:47 EST Message-Id: <9404080021.AA23171@atlas> From: paul@atlas.abccomp.oz.au Date: Fri, 8 Apr 1994 10:21:46 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: WSAENOBUFS error from WSAAsyncGetXXXByYYY I've got a problem with my stack testing, and would like to take another straw poll (results of the last one soon!) The application is expecting all error returns from WSAAsyncGetXXXByYYY routines to be returned along with the completion message. Some conditions, however, are detectable at the time the call is made. The one causing the trouble at the moment is WSAENOBUFS. If the application calls WSAAsynGetHostByName with buf==NULL, I fail the call immediately, instead of accepting the call then immediately posting a message with WSAENOBUFS in LPARAM. Now failing the call immediately seems to be perfectly valid from my reading of the spec - what do you all do/say/expect? -- 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 Apr 8 02:45:21 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13407; Fri, 8 Apr 1994 09:45:27 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA05627; Fri, 8 Apr 94 08:45:31 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DA56E04-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Fri, 08 Apr 94 08:45:21 CST Subject: Re: Curious behaviour from winsock To: winsock-hackers@sunsite.unc.edu Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII icode@teleport.com (Mark Clouden) writes: >When using non blocking sockets with lingering enabled (l_onoff=1, >l_linger!=0), I call closesocket and get WSAEWOULDBLOCK back. Now great, >I expected that, but where is my notification message when it does >close?? Or actually, when will it close? - because according to my >network monitor app the socket is still connected. > I don't know about the second problem (the connection not actually closing), but I wouldn't expect you would get any more notifications on a socket after you closesocket it, since the socket descriptor is then invalidated. If you want full graceful shutdown and notifications along the way, I would suggest shutting down for writing to close your end, and reading 'til "end-of-file" to detect the other side's close. **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 **************************************** From rcq@mailserv-D.ftp.com Sat Apr 9 07:28:11 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01251; Sat, 9 Apr 1994 11:29:17 -0400 Received: from ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:06 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:06 -0400 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19973; Sat, 9 Apr 94 11:28:11 EDT Date: Sat, 9 Apr 94 11:28:11 EDT Message-Id: <9404091528.AA19973@mailserv-D.ftp.com> To: stcheng@ee.tamu.edu Subject: Re: setoptsock() 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 Sat Apr 9 11:28:07 1994] Originating-Client: hurricane.ftp.com Content-Length: 2244 > setoptsock() allows socket programmers to modify the socket > options, like the buffer size for sending and receiving.(using > level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF) > > My question is when the _receiving_ buffer size is bigger than one UDP packet, > say 5 times. Will the incoming 5 packets be held in the buffer if > the app doesn't read it ? Or no matter how big the buffer size is, > it always holds just one UDP packet and discard the subsequence UDP > packets if the apps doesn't read it ? What about if the buffer size > is 5.3 times of the size of the incoming UDP packets , would the > 6th one be stuffed into the remaining buffer size -- .3 of the UDP > packet ? The spec is clear: "if the datagram is larger than the buffer supplied, the buffer is filled with the first part of the datagram, the excess data is lost, and recv() returns the error WSAEMSGSIZE." Where's the ambiguity? Basically, if you snooze, you lose :) > And how about the _sending_ buffer for this case ? I'm not sure how you'd apply the same question to a send(), but I'll take this opportunity to point out a relevant problem with send()/sendto() and UDP datagrams. Our WinSock and stack are incapable of re-assembling incoming oversized datagrams, but we *can* fragment (out-going) data- grams. The reason for this asymmetry is simple: to re-assemble incoming datagrams we would need multiple packet buffers, but we can use a single packet buffer as we send each outgoing fragment. This raises an issue because the WSAData structure only has one iMaxUdpDg size; it doesn't differentiate betweeen poten- tially different sending and receiving datagram sizes. The documentation for send() says it should fail with an error of WSAEMSGSIZE if "the datagram is larger than the maximum supported by the Windows Sockets implementation" (e.g. the iMaxUdpDg value). I admit, we violate the spec in this regard. But I contend that we are justified in doing so because the lack of an asymmetrical send/recv iMaxUdpDg represents a deficiency in the specification. Comments? -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Sat Apr 9 07:28:38 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01287; Sat, 9 Apr 1994 11:29:34 -0400 Received: from ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:33 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:33 -0400 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19990; Sat, 9 Apr 94 11:28:38 EDT Date: Sat, 9 Apr 94 11:28:38 EDT Message-Id: <9404091528.AA19990@mailserv-D.ftp.com> To: ICH211@ZAM001.ZAM.KFA-JUELICH.DE Subject: Re: Closing and reusing sockets 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 Sat Apr 9 11:28:14 1994] Originating-Client: hurricane.ftp.com Content-Length: 2292 > I got the same reply from FTP Software about "no bind used internally" etc, Specifically, you got it from me, just like Bryan did. :) > which I actually don't find acceptable. I believe that sample code in a > specification should work with all compliant implementations, otherwise the > implementation is *not* specification compliant. Since the FTP Winsock.DLL > surely has access to all pending connection info it should be able to > determine at bind() time if there is a local address in use, and return > EADDRINUSE if necessary. What I had to do in my code is to have the bind() I don't disagree, we should be compliant. What I've described to you and Bryan is just a fact of life with PCTCP. Believe me, I don't like it either. Don't you think I'd change it if I had "access to all pending connection info" as you say the WinSock surely does? It would be much easier to change it, than to spend time telling customers how to code around this deficiency. Fortunately, there are very few protocols that require any binding for clients. You two have found two of them: rsh and lpr. I am sorry you need to do the extra coding for our WinSock. I will help you all I can, but the fact is if you want to work on our WinSock the extra effort is required. > loop followed by a connect() as it should be, and have another loop around > all this to try a new port if the connect() fails. Our WIN4RPC DLL had to implement its own rresvport() (sp?) function to get a reserved port number. To avoid the *SAME PROBLEM* that you have encountered, our RPC developer used the current time as a seed into the (pseudo)random() function to get a initial port between 512 and 1024 for bind() (and as the DLL progresses, it increments the port number). I have yet to hear of a case when this has caused a subsequent WSAEADDRINUSE and it is used *heavily*. This is one alternative to the bind()/connect() loop. I know that Bryan doesn't like it because there's still a chance that bind() can succeed and subsequent connect() fail, but I don't think this is a realistic concern ...and I don't consider myself a gambling man :) Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Sat Apr 9 07:28:42 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AB01300; Sat, 9 Apr 1994 11:29:38 -0400 Received: from ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:37 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:37 -0400 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19993; Sat, 9 Apr 94 11:28:42 EDT Date: Sat, 9 Apr 94 11:28:42 EDT Message-Id: <9404091528.AA19993@mailserv-D.ftp.com> To: bryan@alex.com Subject: Re: Closing and reusing sockets 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 Sat Apr 9 11:28:18 1994] Originating-Client: hurricane.ftp.com Content-Length: 1155 > Aha! I was working on the assumption that EADDRINUSE referred to the > *local* address, not the remote address. The spec doesn't specify -- > is there any other explicit reference? I see that Stevens "Unix Network > Programming" does use it as you describe in the rcmd example, page 570. A socket is identified by what Stevens calls the 5-tuple: - Protocol - Local IP address - Local Port Number - Remote IP address - Remote Port Number You get a WSAEADDRINUSE iff *all 5* elements match between two sockets. The reason doing a bind() on a client is not recommended is because commonly the one thing that differs in subsequent connections between a client and *the same* server is the local port number on a client socket. Servers *must* bind() to the same port number each time, because the port number identifies their service. Clients typically need not bind() to a port, since an arbitrary port number is typically acceptable. RSH and LPR are two of the few exceptions. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Sat Apr 9 07:28:25 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01579; Sat, 9 Apr 1994 11:31:45 -0400 Received: from ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:30 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 9 Apr 1994 11:29:30 -0400 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19987; Sat, 9 Apr 94 11:28:25 EDT Date: Sat, 9 Apr 94 11:28:25 EDT Message-Id: <9404091528.AA19987@mailserv-D.ftp.com> To: winsock-hackers@sunsite.unc.edu Subject: closesocket()/WSACleanup() question From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: SawatH@msmailhq.netimage.com Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Sat Apr 9 11:28:10 1994] Originating-Client: hurricane.ftp.com Content-Length: 2573 One of our customers recently brought a statement in the documen- tation for WSACleanup() to my attention. I am amazed that the section he quoted made it into the specification at all, let alone the fact it's never been questioned since. Here is the customer's message text (forwarded with his permission): > I see this as a bug in the implementation. There shouldn't > be any need to wait for the TCP close to complete before the > call to WSACleanup(). Winsock spec 1.1 said > > "Any open SOCK_STREAM sockets that are connected when > WSACleanup() is called are reset; sockets which have been closed > with closesocket() but which still have pending data to be sent > are not affected--the pending data is still sent." > > As you see, it explicitly said that in the last statement. This > is also comfirm by the same behavior in other TCP/IP vendors such > as Lan Workplace, BW, and NetManage. This requirement is inappropriate for a few reasons: - It's not possible to have a DLL that complies with this requirement, unless it has a seperate process that exists independently of the DLL (so it survives the DLL, after a process has called WSACleanup() and Windows has called WEP() and unloaded the DLL from memory). Hence, the specification is making an unreasonable architectural requirement. - Since a call to WSACleanup() means an application has severed it's communication with the WinSock DLL and stack, there is no way for the WinSock to subsequently notify the application in the event of a failure. Networks fail sometimes. Computers do too. Since the network or remote computer can fail after the application calls WSACleanup(), there is no way a WinSock DLL or stack can absolutely guarantee data delivery or a graceful close. So, a DLL cannot be faulted if it resets the connection when an application calls WSACleanup(), even if closesocket() was called before. The application wouldn't know the difference either way. My take on it is that if an application really cares about its data and/or having a graceful close of the connection, then it should wait until the socket is closed before calling WSACleanup(). In other words, the onus should be on the application, not on the WinSock DLL and stack. This is easily accomplished in an applica- tion with FD_CLOSE notification, among other methods. Comments? -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Sat Apr 9 13:34:48 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18457; Sat, 9 Apr 1994 17:35:44 -0400 Received: from ftp.com by ftp.com ; Sat, 9 Apr 1994 17:35:42 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 9 Apr 1994 17:35:42 -0400 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21634; Sat, 9 Apr 94 17:34:48 EDT Date: Sat, 9 Apr 94 17:34:48 EDT Message-Id: <9404092134.AA21634@mailserv-D.ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: WSAENOBUFS error from WSAAsyncGetXXXByYYY 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 Sat Apr 9 17:34:45 1994] Originating-Client: hurricane.ftp.com Content-Length: 811 > The application is expecting all error returns from WSAAsyncGetXXXByYYY > routines to be returned along with the completion message. > Some conditions, however, are detectable at the time the call is made. > The one causing the trouble at the moment is WSAENOBUFS. If the application > calls WSAAsynGetHostByName with buf==NULL, I fail the call immediately, > instead of accepting the call then immediately posting a message with > WSAENOBUFS in LPARAM. Now failing the call immediately seems to be > perfectly valid from my reading of the spec - what do you all > do/say/expect? We post the error in a reply, but I think your reading of it is correct also. -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Sat Apr 9 13:34:59 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18482; Sat, 9 Apr 1994 17:35:55 -0400 Received: from ftp.com by ftp.com ; Sat, 9 Apr 1994 17:35:54 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 9 Apr 1994 17:35:54 -0400 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21637; Sat, 9 Apr 94 17:34:59 EDT Date: Sat, 9 Apr 94 17:34:59 EDT Message-Id: <9404092134.AA21637@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: Multiple recipients of list Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Sat Apr 9 17:34:55 1994] Originating-Client: hurricane.ftp.com Content-Length: 1571 > icode@teleport.com (Mark Clouden) writes: > >When using non blocking sockets with lingering enabled (l_onoff=1, > >l_linger!=0), I call closesocket and get WSAEWOULDBLOCK back. Now great, > >I expected that, but where is my notification message when it does > >close?? Or actually, when will it close? - because according to my > >network monitor app the socket is still connected. > > I don't know about the second problem (the connection not actually > closing), but I wouldn't expect you would get any more notifications on a > socket after you closesocket it, since the socket descriptor is then > invalidated. If you want full graceful shutdown and notifications along > the way, I would suggest shutting down for writing to close your end, and > reading 'til "end-of-file" to detect the other side's close. I agree with your suggested method for the most robust way to close a socket; that's what we recommend also. But it's certainly reasonable to call closesocket() and expect an FD_CLOSE when the graceful close completes (e.g. FIN response received, so TIME_WAIT state entered) or the graceful close attempt times out. For example, 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." Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Mon Apr 11 05:28:52 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13912; Sun, 10 Apr 1994 20:16:05 -0400 Received: by usage.csd.unsw.OZ.AU id AA22107 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 11 Apr 1994 10:15:46 +1000 Received: by atlas (4.1/1.35) id AA01926; Mon, 11 Apr 94 10:28:53 EST Message-Id: <9404110028.AA01926@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 11 Apr 1994 10:28:52 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: stcheng@ee.tamu.edu, Multiple recipients of list Subject: Re: setoptsock() Thus expounded Franklin S. Cheng on Apr 8,11:19pm: /-------------------- | |Fellow hackers, | |setoptsock() allows socket programmers to modify the socket |options, like the buffer size for sending and receiving.(using |level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF) | |My question is when the _receiving_ buffer size is bigger than one UDP packet, |say 5 times. Will the incoming 5 packets be held in the buffer if |the app doesn't read it ? Or no matter how big the buffer size is, |it always holds just one UDP packet and discard the subsequence UDP |packets if the apps doesn't read it ? What about if the buffer size |is 5.3 times of the size of the incoming UDP packets , would the |6th one be stuffed into the remaining buffer size -- .3 of the UDP |packet ? Most of this is implementation dependent - UDP is _not_ a reliable protocol, and datagrams can be lost at any stage - even once they have safely negotiated the cables and are inside the machine! On the other hand, an implementation that prevented th euser from receiving all the packets possible would be seriously deficent. All I can describe is our implementation, which (naturally) I believe to be the only sensible method :) Multiple incoming UDP packets are queued, unless the new packet would take the total aggregate buffer size over the receive buffer limit - i.e. in your example above, if the receive buffer was 5.3 times larger than the incoming packets, the first 5 would be queued, the sixth and subsequent packets would be dropped until some of the successful packets have been read. On the other hand, we don't implement changing the UDP receive buffer at all, so calling setsockopt(SO_RCVBUF) ona UDP socket doesn't acheive a great deal! (its conceptually 4K fixed presently). This may be implemented soon. |And how about the _sending_ buffer for this case ? Actually, I don't believe the concept of a sending buffer is applicable for a UDP socket - each send() by the application results in a separate datagram, which can be sent immediately to the output interface. If you send too many too fast for the interface, they get dropped from the output interface queue, which is totally unrelated to any socket. | |thanks, Anytime. | |Franklin. Cheers, -- 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 Apr 11 06:01:34 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18479; Sun, 10 Apr 1994 20:49:09 -0400 Received: by usage.csd.unsw.OZ.AU id AA23690 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 11 Apr 1994 10:48:30 +1000 Received: by atlas (4.1/1.35) id AA02023; Mon, 11 Apr 94 11:01:36 EST Message-Id: <9404110101.AA02023@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 11 Apr 1994 11:01:34 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: bryan@alex.com, Multiple recipients of list Subject: Re: Closing and reusing sockets Thus expounded Bryan Boreham on Apr 8,11:40pm: /-------------------- |>From Paul Brooks, paul@abccomp.oz.au: | |>True, but you still have to think about the case where your local machine |>has closed the socket down OK, allowing you to BIND to the same |>port number in the future, but the REMOTE end still has the same |>port/address association valid, probably in TIMEWAIT state for two minutes. |> |>In this case, your bind() will succeed, but the remote end may well refuse |>the connection. WSAEADDRINUSE is a valid return from connect(), | |Aha! I was working on the assumption that EADDRINUSE referred to the |*local* address, not the remote address. The spec doesn't specify -- |is there any other explicit reference? I see that Stevens "Unix Network |Programming" does use it as you describe in the rcmd example, page 570. I wasn't aware of the passage, I was remembering some bad experiences I have had, making unwarranted assumptions that just because one end has forgotten about a previous connection, the other end has too. When you look at the sequence of closing a socket - the FIN, FIN/ACK, ACK exchange - its the end that initiates the first FIN that ends up in the two minute long TIME-WAIT state, while the other end can forget the connection completely. For client/server things, usually its the server end that ends up doing this, in response to a signal from the client (i.e. Telnet, where the server closes the connection after the user types 'logout' or '^D', or FTP data connections, where the end thats sending does the close). In this case, the local end can successfully bind() to a previously used local port, and connect() to a previously used remote port. When the SYN gets to the remote end, however, it may find a matching socket in TIME-WAIT, and the remote end may refuse the connection. |However, exactly the same circumstances didn't result in a failure at all |using the Trumpet stack. I think I'll do some network sniffing to see if |I can spot what is different. Just because this is a possible (and probable) connection failure mechanism, I'm still not sure how the local end would distinguish this case and return WSAEADDRINUSE for the connect() return, instead of the more usual WSAECONNREFUSED. Possibly if the remote end returned a FIN, believing the new SYN to be an artifact of the previous connection. | |Here is one specifc case: suppose a program uses rsh twice in |succession, something which is very easy in the Alex language. We must |bind to a free reserved port locally, and we must connect to the same |remote port each time. We would like to do this reliably on any of |the dozen or more Winsock stacks that our customers might use, with |the minimum of hack work-arounds that "just happen to fix it". Use the two-tiered loop around connect() and bind() - don't assume that just because you can bind() to a local port, that the following connect() will succeed. This should work, even with potentially broken stacks that can't check sockets at bind() time properly. -- 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 Apr 11 09:52:24 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19791; Mon, 11 Apr 1994 00:39:11 -0400 Received: by usage.csd.unsw.OZ.AU id AA04534 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 11 Apr 1994 14:39:22 +1000 Received: by atlas (4.1/1.35) id AA03112; Mon, 11 Apr 94 14:52:24 EST Message-Id: <9404110452.AA03112@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 11 Apr 1994 14:52:24 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu, davidtr@microsoft.com Subject: Windows Sockets 1.1 errata list. This is a list of typos and minor irritants I have found in the WinSock 1.1 spec. I'm listing them here since it is likely to me that the 2.0 spec. will borrow much of the text of the 1.1 document, and I would like to see them cleared out for the 2.0 document. I'm also listing some minor issues that need clarifying text within the 1.1 spec, in the hope that they will be included in the 2.0 document, and possibly also in a '1.1 addendum' document. I won't be able to attend the V2.0 discussions at Winsockathon, but would like these issues tabled for discussion there. Typos etc. ---------- Page 25: Superfluous 'r' character just above '4.1.4 connect() should be removed. Page 26: WSAEINVAL is not a possible error code for connect(), and it should be removed. Connect() will perform an automatic internal bind() if required, as already described in the Remarks section. Page 27: Add text to WSAEFAULT error explanation: ..., or one or both of name and namelen are not valid pointers. Page 29: The type of optname (int) clashes with the declared type of the SO_DONTLINGER socket option in WINSOCK.H (u-int). Suggest changing WINSOCK.H to make SO_DONTLINGER a signed integer to accomodate developers using strict environments. e.g. #define SO_DONTLINGER (int)(~SO_LINGER). Page 36: Add 'WSAEFAULT argp is not a valid pointer' to Error Codes section. Page 42; Add 'WSAEFAULT buf is not a valid pointer' to error codes section. Page 43: second-last paragraph in Remarks section, bottom of page: "If the connection has been reset recv() will fail..." - recv() should be recvfrom(). Page 44: The WSAEFAULT explanation should begin "The from and/or fromlen argument(s) was invalid" Page 47: Add "WSEFAULT one of the argument pointers was invalid" to Error Codes Section. Page 55: In setsockopt, in the table at top of P55, the line for SO_ERROR should be removed, its a hangover from a block copy from getsockopt(). Page 60: Halfway down in the explanation of the members of the hostent structure, the "(PC)" should be removed from the h_name entry - theres nothing specific in a hostent entry for a PC, and the return from gethostbyYYY need not be a PC. Page 62: The title at the top of the page containing '4.2.2 gethostbyname' reads 'gethostname', wheras the actual 'gethostname' page is the next one. This should be changed to 'gethostbyname'. Page 69: Remarks section: "getservbyport() returns a pointer to a .." ^^^ Word 'to' must be inserted. Page 105: Remarks section, 2nd para., 4th sentence currently reads "If this version is higher than the lowest version supported by the DLL". I beleive this should read "... higher or equal to ...". Implementations using this literally may fail to correctly register v1.1 applications when the DLL supports versions v1.1 and higher (e.g. 2.0). Clarifications and minor additions ---------------------------------- Page 25/26: connect(). The BSD form of connect() allows multiple connect() functions to be called for SOCK_DGRAM (And presumably SOCK_RAW) sockets, to change the remote destination binding. Also, it allows connect()ing to an invalid address (usually all zeros) to mean 'disconnect' the socket, and start accepting datagrams from all remote sources. For this functionality to be described by the Winsock Spec, the following alterations need to be made: remarks section, 1st para, change last sentence to: "..., connect() will return WSAEDDRNOTAVAIL for SOCK_STREAM sockets. Datagram-based sockets (SOCK_DGRAM, SOCK_RAW) will be 'disconnected', and start accepting datagrams from multiple remote sources. Add new sentences to last paragraph about SOCK_DGRAM sockets: "Multiple connect() calls may be used to alter the default remote destination, and a connect() call with a name containing all zeros will return the socket to a 'dis-connected' state. Error codes: Add (SOCK_STREAM only) to the explanation for WSAEADDRNOTAVAIL and WSAEISCONN error codes. P35, ioctlsocket(). The argp argument points to a 'u_long FAR *', and all commands except SIOCATMARK specify their arguemnts to be real unsigned long values. SIOCATMARK, however, states that 'argp' points to a BOOL. Now a BOOL is defined as an int, which size is different on different processor architectures, and it is unclear whether this command should operate on a 16-bit or 32-bit quantity - there exist implementations of DLLs and applications that assume both - this confusion is very bad for interoperability. I beleive the best solution is for ioctlsocket() to always operate on 32-bit (or at least, 'u_long') quantities, and that the last sentence on page 35 should read something like: "argp points at an unsigned long, in which ioctlsocket() stores the result: either FALSE (0) or TRUE (!0)." P 48, send() The description for send() seems to prohibit the harmless practice of calling send() with a length of 0. A recent poll conducted by myself came back 4:1 in favour of send() allowing a length of 0, and in this case the valid return code of 0 indicates 'all requested data sent' as expected. This seems to be common practice in many, but not all implementations, anyway. I propose the third paragraph in the Remarks section add some text to legitimise this practice. -- 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 David_B_Andersen@ccm.jf.intel.com Mon Apr 11 10:06:49 1994 Received: from ormail.intel.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24399; Mon, 11 Apr 1994 21:06:53 -0400 Received: from ccm.hf.intel.com by ormail.intel.com (Smail3.1.28.1 #2) id m0pqWwD-000MNbC; Mon, 11 Apr 94 18:06 PDT Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 11 Apr 94 18:06:49 PST Date: Mon, 11 Apr 94 18:06:49 PST From: David B Andersen Message-Id: <940411180649_1@ccm.hf.intel.com> To: winsock-hackers@SunSITE.Unc.EDU Subject: Re: WSAENOBUFS error from WSAAsyncGetXXXByYYY IMHO, the correct behaviour is to return the async task handle (what a misnomer!) and then post a message with the WSAENOBUFS error code. My reasons for believing this is that WSAENOBUFS is *not* one of the defined error codes for the situation when the asynchronous operation could not be (or simply was not) launched. --Dave B. Andersen Intel Architecture Labs ______________________________ Reply Separator _________________________________ Subject: WSAENOBUFS error from WSAAsyncGetXXXByYYY Author: winsock-hackers@SunSITE.Unc.EDU at Internet_Gateway Date: 4/9/94 1:21 AM I've got a problem with my stack testing, and would like to take another straw poll (results of the last one soon!) The application is expecting all error returns from WSAAsyncGetXXXByYYY routines to be returned along with the completion message. Some conditions, however, are detectable at the time the call is made. The one causing the trouble at the moment is WSAENOBUFS. If the application calls WSAAsynGetHostByName with buf==NULL, I fail the call immediately, instead of accepting the call then immediately posting a message with WSAENOBUFS in LPARAM. Now failing the call immediately seems to be perfectly valid from my reading of the spec - what do you all do/say/expect? -- 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 Apr 13 04:08:23 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15014; Tue, 12 Apr 1994 18:55:19 -0400 Received: by usage.csd.unsw.OZ.AU id AA25725 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 13 Apr 1994 08:55:16 +1000 Received: by atlas (4.1/1.35) id AA03728; Wed, 13 Apr 94 09:08:24 EST Message-Id: <9404122308.AA03728@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 13 Apr 1994 09:08:23 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: WSAAsyncGetXXXbyYYY returns revisited Recently I posted asking for opinions on failing WSAAsyncGetXXXbyYYY calls immediately, if the implementation could decide then the call would not succeed, i.e. if the buffer parameter was NULL. While I had a couple of messages indictaing it seemed a fair thing to do, Scott Robins reminded me: Thus expounded Question Reality 11-Apr-1994 0956 -0400 on Apr 11, 9:56am: /-------------------- | |I think that failing it immediately would be a reasonable action. However, |I just don't think that the spec reads that way. And since V1.1 is already |out there, I don't see a need to change this behaviour. ...and after reading the spec again carefully, I realise I was mis-interpreting the text, and that it is reasonably explicit in saying that only if the call could not be initiated or queued for some reason should the initial call fail. I agree with Scott here - it might be a reasonable thing to do, but it isn't compliant with the published spec. - so I'll be changing our stack. Thanks all. -- 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 dudley@hosv1.att.com Wed Apr 16 02:02:00 1994 Received: from gw1.att.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07149; Fri, 15 Apr 1994 22:02:47 -0400 To: winsock-hackers@SunSITE.Unc.EDU Received: from hosv1.UUCP by ig1.att.att.com id AA29976; Fri, 15 Apr 94 22:02:51 EDT Message-Id: <9404160202.AA29976@ig1.att.att.com> From: dudley@hosv1.att.com Date: 16 Apr 94 02:02:00 GMT Apparently-To: winsock-hackers@SunSITE.Unc.EDU I will be away from the office from April 18, 1994 until April 25,1994. I will pick up e-mail messages on or about April 25, if you have a question or concern that can not wait until that time, please call x-3800 for system related problems or concerns or x-4464 for plotter releated problems or concerns. Dudley From paul@atlas.dev.abccomp.oz.au Mon Apr 18 05:37:47 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA29318; Sun, 17 Apr 1994 20:24:25 -0400 Received: by usage.csd.unsw.OZ.AU id AA24894 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 18 Apr 1994 10:24:32 +1000 Received: by atlas (4.1/1.35) id AA05577; Mon, 18 Apr 94 10:37:48 EST Message-Id: <9404180037.AA05577@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 18 Apr 1994 10:37:47 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: setoptsock() Thus expounded Bob Quinn on Apr 15,10:01pm: /-------------------- |> setoptsock() allows socket programmers to modify the socket |> options, like the buffer size for sending and receiving.(using |> level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF) |> |> My question is when the _receiving_ buffer size is bigger than one UDP packet, |> say 5 times. Will the incoming 5 packets be held in the buffer if |> the app doesn't read it ? Or no matter how big the buffer size is, |> it always holds just one UDP packet and discard the subsequence UDP |> packets if the apps doesn't read it ? What about if the buffer size |> is 5.3 times of the size of the incoming UDP packets , would the |> 6th one be stuffed into the remaining buffer size -- .3 of the UDP |> packet ? | |The spec is clear: "if the datagram is larger than the buffer |supplied, the buffer is filled with the first part of the |datagram, the excess data is lost, and recv() returns the |error WSAEMSGSIZE." Where's the ambiguity? Basically, if |you snooze, you lose :) Bzzt: sorry Bob, I think you are talking about the wrong buffer. I beleive that passage you quoted refers to the buffer provided by the caller in the recv() call - if the LEN parameter is only, say, 1K, and the queued datagram is, say, 2K, thn you only get the first 1K of the queued datagram, as you said. The question, on the other hand, was about the internal socket buffer for all the queued datagrams - the one affected by the SO_RCVBUF socket option. This is a different kettle of fish. |I admit, we violate the spec in this regard. But I contend |that we are justified in doing so because the lack of an |asymmetrical send/recv iMaxUdpDg represents a deficiency in |the specification. | |Comments? Given that fragmentation of outgoing datagrams is simple, all the way up to the full 64K size of a maximum IP datagram, I don't believe any implementation _will_ have a need for a separate limit on the size of outgoing UDP datagrams, and that the iMaxUdpDg parameter relates to the maximum size the implementation is prepared to re-assemble from incoming fragments. Otherwise you get people setting up 'black holes' when they set things up to use the same maximum-size UDP datagrams out and in. If you have a separate size of maximum outgoing and maximum incoming datagrams, the iMaxUdpDg parameter should be set to the lower of these, to warn the poor application that the underlying stack may be insufficient for its requirements. -- 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 Apr 18 05:48:32 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00619; Sun, 17 Apr 1994 20:35:59 -0400 Received: by usage.csd.unsw.OZ.AU id AA25378 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 18 Apr 1994 10:35:15 +1000 Received: by atlas (4.1/1.35) id AA05611; Mon, 18 Apr 94 10:48:32 EST Message-Id: <9404180048.AA05611@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 18 Apr 1994 10:48:32 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: closesocket()/WSACleanup() question Thus expounded Bob Quinn on Apr 15,10:26pm: /-------------------- |One of our customers recently brought a statement in the documen- |tation for WSACleanup() to my attention. I am amazed that the |section he quoted made it into the specification at all, let alone |the fact it's never been questioned since. Here is the customer's |message text (forwarded with his permission): | |> I see this as a bug in the implementation. There shouldn't |> be any need to wait for the TCP close to complete before the |> call to WSACleanup(). Winsock spec 1.1 said |> |> "Any open SOCK_STREAM sockets that are connected when |> WSACleanup() is called are reset; sockets which have been closed |> with closesocket() but which still have pending data to be sent |> are not affected--the pending data is still sent." |> |> As you see, it explicitly said that in the last statement. This |> is also comfirm by the same behavior in other TCP/IP vendors such |> as Lan Workplace, BW, and NetManage. | |This requirement is inappropriate for a few reasons: [etc] My thoughts are that these requirements can be met, _PROVIDED_ this is not the last app. to call WSACleanup() - in this case, the DLL stays in memory and can manage the data. The requirements are still met by specific implementations - ours, where a DOS TSR manages the sending of data, independently of the presence or absence of a DLL, and probably a similar case if a VxD is used. Bob is correct, though - those requirements are not appropriate in general, and cannot be guaranteed by a pure DLL implementation of Windows Sockets, because the DLL will have to chuck the data when it unloads. I guess they might be beleiving an application will call WSACleanup(), then hang araound for a while doing other things, or something. I agree, Bob, - there is no way to guarantee in all cases that data pending to be sent on a closed socket will still be sent after WSACleanup() is called, no matter what the spec. says. -- 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 roger.kries@crpht.lu Mon Apr 18 13:55:56 1994 Received: from arthur.crpht.lu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20414; Mon, 18 Apr 1994 06:56:45 -0400 Message-Id: <199404181056.AA20414@SunSITE.Unc.EDU> Received: from buster.crpht.lu by arthur.crpht.lu with SMTP (1.37.109.4/16.2) id AA18472; Mon, 18 Apr 94 12:57:05 +0200 X-Sender: kries@arthur.crpht.lu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Apr 1994 12:55:56 +0100 To: winsock-hackers@sunsite.unc.edu From: roger.kries@crpht.lu (Roger Kries) Subject: Q: How to connect with a timeout ? I'm having some problems writing Berkley Sockets API compatible code to connect to a machine with a timeout value. That's to say, I want to connect to a machine, but if I cannot connect until the timeout is elapsed I give up. My solution was to call connect() on a non-blocking socket and then to call select() with the timeout value and to check if the socket is writeable. This method is described in the Winsock specification at page 25: > On a non-blocking socket, if the return value is SOCKET_ERROR an > application should call WSAGetLastError(). If this indicates an error > code of WSAEWOULDBLOCK, then your application can either: > 1. Use select() to determine the completion of the connection by > checking if the socket is writeable, or > 2. ... The second method is not Berkley Sockets compatible. All this seems to be very fine, but after testing the method on a PC with Trumpet Winsock.dll, on a macintosh with a special socket library (GUSI) and on a HP-UX machine, the following problem arises: 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. From bruce@isi.FrontierTech.COM Mon Apr 18 02:38:09 1994 Received: from isi.FrontierTech.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15970; Mon, 18 Apr 1994 09:37:54 -0400 Received: from bruces.FrontierTech.COM by isi.FrontierTech.COM (5.65/1.40) id AA07274; Mon, 18 Apr 94 08:37:18 -0500 X-Mailer: SuperTCP/NFS for Windows Version 4.00 (Mailer Version 1.02) Message-Id: <2DB29B55-00000001@Bruces.FrontierTech.COM> From: Bruce@isi.FrontierTech.COM Date: Mon, 18 Apr 94 08:38:09 CST Subject: Re: Curious behaviour from winsock To: winsock-hackers@sunsite.unc.edu Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII Bob Quin writes: > >I agree with your suggested method for the most robust way to >close a socket; that's what we recommend also. But it's certainly >reasonable to call closesocket() and expect an FD_CLOSE when the >graceful close completes (e.g. FIN response received, so TIME_WAIT >state entered) or the graceful close attempt times out. > >For example, 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. 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? **************************************** Bruce A Backman (Bruce@FrontierTech.COM) Frontier Technologies Corporation 10201 North Port Washington Road Mequon, WI 53092 **************************************** From dob@tis.inel.gov Tue Apr 19 09:50:13 1994 Received: from mica.inel.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08525; Tue, 19 Apr 1994 17:49:38 -0400 Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov (4.1/INEL-MH-10.0) id AA19799; Tue, 19 Apr 94 15:49:36 MDT Received: by dewey.inel.gov (5.65/INEL-WKS-2.0) id AA18762; Tue, 19 Apr 1994 15:50:13 -0600 Date: Tue, 19 Apr 1994 15:50:13 -0600 Message-Id: <9404192150.AA18762@dewey.inel.gov> From: dob@inel.gov To: winsock-hackers@sunsite.unc.edu Subject: a redirecting DLL Hi folks, How does one go about making a redirecting DLL? For instance, if one had the need to intercept all messages going to, say, WINSOCK.DLL, how would you do this? A simple example of such a DLL might be something that showed requests and responses. This would be a kind of "pass through" DLL, not very involved at all, and once it worked correctly it could be a great diagnostic tool, among other things. A little more involved DLL might be something that implemented one of the proxy protocols, say SOCKS. With such a DLL all WinSock clients would instantly become SOCKSified; well, in my dreams, of course, but it would probably work well for the majority of clients. If anyone can point me to some reference materials, or other helpful information, I would certainly appreciate it. Also, if I developed it here at work, I would try to make it freely available, like wslpd and WSGopher are now. Chances are good that I'd succeed. Thanks in advance! Best regards, 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 ------------------------------------------------------- From martinh@jsbus.com Wed Apr 20 02:14:13 1994 Received: from jsbus.jsbus.com (jsbus.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20754; Wed, 20 Apr 1994 12:15:08 -0400 Received: by jsbus.jsbus.com id aa12214; 20 Apr 94 9:15 PDT From: Martin Hall To: winsock-hackers@sunsite.unc.edu, winsock-users@sunsite.unc.edu Subject: *** WinSock 2 Announcement *** X-Mailer: SCO Portfolio 2.0 Date: Wed, 20 Apr 1994 9:14:13 -0700 (PDT) Message-Id: <9404200914.aa12138@jsbus.jsbus.com> This is a little later than we'd intended because of various things we've wanted to finalize... Here's important data for all of you interested in the NEXT version of Windows Sockets. Please note we've worked hard to try and incorporate all suggestions and experience into this. If you have ideas or requests, it doesn't mean you've lost your chance. On the contrary, your participation is encouraged. Please note, however, that we don't want to start email discussion of the following until AFTER the Interop meeting. Following that meeting we will publish details of that meeting and any refinements to the following. THEN we will get into the real technical discussions. So please hold of with WinSock 2 email until then. thanks everyone Martin (on behalf of Martin, Dave & Mark) --------------------------------------------- Windows Sockets Version 2 - Kick Off Details --------------------------------------------- Date: April 18, 1994 Authors: Martin Hall, Dave Treadwell, Mark Towfiq This document is organized as follows 1. Objectives (Why are we doing this?) 2. Overview (What's it all about?) 3. Organizational Framework 3.1 Moderators 3.2 Review Boards 3.2.1 Application Review Board 3.2.2 Transport Review Board 3.3 Design/Functionality Groups 3.3.1 Generic API Extensions & Additions 3.3.2 Specification Clarifications 3.3.3 Name Resolution 3.3.4 Operating Framework 3.3.5 TCP/IP 3.3.6 IPX/SPX 3.3.7 Appletalk 3.3.8 Telephony 3.3.9 OSI 4. Timeframes 5. Discussion Forums 6. Key Dates 7. Actions Required -------------------------------------- 1. Objectives (Why are we doing this?) -------------------------------------- Windows Sockets has succeeded to date because 1. It has met the needs of application developers ("I'm tired of all these different API's!") 2. It has led to easier decisions for end users ("I want a WinSock app, I want a WinSock compliant stack and I want them now!") 3. It's been fun and pursued in a great spirit of cooperation The burgeoning implementation of LAN environments, the rise and rise of TCP/IP, the widespread acceptance of Windows Sockets in the application developer community and amongst application users have all helped make Windows Sockets something of a de facto standard in a very short period of time. It is therefore natural to consider amending and extending Windows Sockets to make it the de facto transport API for all data communication irrespective of protocol. ---------------------------------- 2. Overview (What's it all about?) ---------------------------------- The Windows Sockets Version 2 specification will extend Windows Sockets Version 1.1 in 3 key areas 1. API Extensions Over 2 years experience of Windows Sockets has led to various suggestions for improvements to the existing specification. There are a number of proposals for API additions and extensions which make it even easier for application developers to utilize Windows Sockets implementations. Some of these extensions are likely to be generically applicable, some will be transport specific. 2. Multiple Network Transport Capabilities The success of version 1.1 of Windows Sockets has led to a clamour for support of network transports other than TCP/IP. Requests have been made to design support for IPX/SPX and AppleTalk specifically. In response to demand for a standard data transfer API for emerging technology such as ATM and telephony-based transports, there will also be consideration of how best to enable this in a Windows Sockets framework. The design groups in Windows Sockets 2 will also seek to create a generic architectural framework that will host any network transport. 3. Operating System Considerations & Architectural Issues The Microsoft Windows Operating System platforms will soon be extended beyond Windows 3.1 and Windows NT for which Windows Sockets 1.1 was designed. Windows Sockets Version 2 will take into account not just these platforms but forthcoming versions of both Windows NT and Chicago. An important goal of WinSock 2 is thus ensuring that WinSock applications can be well-integrated within these operating systems. --------------------------- 3. Organizational Framework --------------------------- The success of Windows Sockets 1.1, the complexity and breadth of issues under discussion for Windows Sockets version 2 and the number of people now involved in the various Windows Sockets forums means we need a little clearer operational structure for progress this time around. In order to allow everyone to contribute to areas which they care about we have designed the following operational structure to facilitate discussion and to enable maximum progress. The most important groups are the Review Boards and Functionality/Design Groups. Together, these groups will be responsible for discussing, designing and agreeing on the practicality of new functionality. -------------- 3.1 Moderators -------------- Martin Hall, Dave Treadwell and Mark Towfiq will act largely as coordinators. ------------------ 3.2 Review Boards ------------------ The reason for establishing Review Boards is to enable the ongoing pragmatic goals of Windows Sockets to be realized. In the world of Windows Sockets, pragmatism is defined by 1. The applicability of Windows Sockets functionality to application developers. 2. The ease with which functionality can be implemented by Windows Sockets providers (typically, but not necessarily, network transport vendors) To this end, we would like to set up 2 review boards. Each board will review submissions from each Functionality Group in the light of the pragmatic goals of Windows Sockets. 3.2.1 Application Review Board ------------------------------- Charter: The Application Review Board will review submissions from each Functionality Group. It will focus on the submission's applicability to and ease of use by application developers as well as confirming that functionality required by applications is supported. Membership: A maximum of one representative from each company will contribute to this group. 3.2.2 Transport Review Board ----------------------------- Charter: The Transport Review Board will review submissions from each Functionality Group. It will focus on the ease of implementation of a piece of functionality. Membership: A maximum of one representative from each company will contribute to this group. 3.3 Design/Functionality Groups ------------------------------- The reason for establishing Design/Functionality Groups is to break up the large body of issues that require discussion for WinSock 2 into manageable chunks. The following groups will also allow people to focus on areas of particular interest and ignore ones they don't care about. 3.3.1 Generic API Extensions & Additions ----------------------------------------- Charter: To design and specify general extensions to the Windows Sockets API. Features and changes should be applicable to multiple transport protocols. Proposals: Improved support for other languages: C++, Basic, Pascal True asynchronous send() and recv() mechanisms Ability to share sockets between tasks/processes "Deferred accept()"--don't establish connection immediately SO_SNDTIMEO and SO_RCVTIMEO socket options 4-byte per-socket context value stored by winsock DLL Standard routine to map winsock error codes to strings Aplication yielding, blocking hooks Socket Groups Support for message-oriented (partial) receives Per-socket query of max message length Support for connect and disconnect data Transaction-oriented transport support Mechanism for querying optional functionality Scatter write, gather read sethostname() Mechanism to retrieve network statistics 3.3.2 Specification Clarifications ----------------------------------- Charter: Resolve ambiguities in the Windows Sockets specification to ensure that all Windows Sockets implementations have a consistent interpretation of the interface. Proposals: WSAAsyncSelect() issues Multiple versions supported by a single winsock DLL Unconnecting datagram sockets FD_CLR performance improvements s_port in servent struct is int Stack space requirements on winsock DLL NULL array pointers in hostent struct Structure packing of servent, protoent winsock.h: all ports, ip addrs in NETWORK order closesocket() on nonblocking sockets Samples for every API FD_READ contains error--> no need for recv() 3.3.3 Name Resolution ---------------------- Charter: Design and specify a name-service independent interface which allows Windows Sockets applicationt to resolve huiman-readable host or service names into Windows Sockets transport addresses (SOCKADDRs). Proposals: Support for other name service providers Host/Service enumeration Internationalizable (unicode) name resolution routines Dynamic service registration Directory Service support Define standard location for database files 3.3.4 Operating Framework -------------------------- Charter: Ensure that Windows Sockets DLLs and transport protocols can coexist in the various operating systems which support Windows Sockets. Proposals: Operating System versions--Win 3.1, WFW, NT, Chicago Configuration Architecture Multiple Transport Procotol Stacks on a single host Multiple Windows Sockets DLLs on a single host Clearinghouse for address familys, protoocls, socket types Mechanism for determining version of winsock DLL 3.3.5 TCP/IP ------------- Charter: Provide TCP/IP-specific extensions to the Windows Sockets API. Proposals: ICMP, Raw Sockets, Ping RFC 793 & 1122 OOB Data support Get/Set/Delete ARP entries gethostid() SIOCGIFADDR, SIOCGARP, SIOCGHIWAT, SIOCGIFNETMASK, SIOCADDRT, etc. Mechanism to set TTL in IP header rresvport() IP multicast support (IGMP) IPng support UDP datagram send size != receive size Standardize OOB handling Option to disable UDP checksum 3.3.6 IPX/SPX -------------- Charter: Provide IPX/SPX-specific extensions to the Windows Sockets API. Proposals: No specific ones as yet 3.3.7 AppleTalk ---------------- Charter: Provide AppleTalk-specific extensions to the Windows Sockets API. Proposals: No specific ones as yet 3.3.8 Telephony ---------------- Charter: Extend Windows Sockets to handle telephony applications including atm, isdn, etc. Proposals: Lots of interest 3.3.9 OSI ---------------- Charter: Provide OSI-specific extensions to the Windows Sockets API. Proposals: No specific ones as yet -------------- 4. Timeframes -------------- We have identified the following broad and hopefully realistic timeframes for Windows Sockets Version 2. May (Interop) - Windows Sockets 2 Kick Off (See below) June 30, 1994 - Functionality Groups Functionality Proposals Complete August 31, 1994 - Functionality Groups First Drafts Complete November 30, 1994 - Functionality Groups Intermediate Drafts Complete January 1, 1995 - Functionality Groups Final Drafts Complete April 30, 1995 - Windows Sockets Version 2 Specification Final --------------------- 5. Discussion Forums --------------------- Email & Newsgroup details With the recent reorganization of the Windows newsgroups, we see a need to: 1. Create a new list for WinSock 2.0 2. Shift the mailing list gated to alt.winsock 3. Re-think winsock-hackers and winsock-users. Here are the new networking-related newsgroups comp.os.ms-windows.networking.tcp-ip Windows and TCP/IP etworking comp.os.ms-windows.networking.windows Windows' built-in networking comp.os.ms-windows.networking.misc Windows and other networks comp.os.ms-windows.programmer.networks Network programming For the current mailing lists we propose to 1. Gate the present winsock mailing list to comp.os.ms-windows.networking.tcp-ip (since, although winsock is not only for TCP/IP, 95% of the traffic on the mailing list is about TCP/IP). 2. Gate winsock-hackers to comp.os.ms-windows.programmer.networks. 3. Drop winsock-users because of minimal usage. For Windows Sockets Version 2 discussion we propose to 1. Create a new mailing list,winsock-2@SunSite.UNC.Edu, for discussion of general issues related to Windows Sockets version 2.0. 2. Create separate mailing lists for individual Review Boards and Functionality Groups. None of these will be gated to a newsgroup, to facilitate focussed discussion. ------------- 6. Key Dates ------------- April 21, 1994, TCP/IP Bake-Off, hosted by Microsoft, Seattle WA Windows Sockets 2 - Informal evening dinner meeting April 21 - 22, TCP/IP Bake-Off, hosted by Microsoft, Seattle WA WinSockathon IV Tuesday May 3 1994, Interop, Las Vegas NV Windows Sockets 2 - Official Kick Off -------------------- 7. Actions Required -------------------- The official Windows Sockets 2 kick-off will take place at Interop, Las Vegas. Interop is really the godfather of Windows Sockets so it's a particularly appropriate venue. If you wish to attend that event discussion please 1. Email the following details to Marty Bickford (martinb@jsbus.com) Name Company Address Contact Telephone Phone Number Please note space is limited and preference will be given to the first person from a particular company who sends such an email. 2. Consider this document the informal working agenda for now, (a formal agenda will be published). ------------------------------------------------------------------------- Martin Hall 108 Whispering Pines Drive, Suite 115 JSB Corporation Scotts Valley, California 95066 martinh@jsbus.com Tel: 408-438-8300 Fax: 408-438-8360 From stcheng@ee.tamu.edu Wed Apr 20 19:28:52 1994 Received: from EE.TAMU.EDU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA21103; Thu, 21 Apr 1994 01:27:20 -0400 Received: by ee.tamu.edu (5.61/1.34) id AA09209; Thu, 21 Apr 94 00:28:53 -0500 From: stcheng@ee.tamu.edu (Franklin S. Cheng) Message-Id: <9404210528.AA09209@ee.tamu.edu> Subject: Essential Winsock problems To: winsock-hackers@sunsite.unc.edu (WINSOCK) Date: Thu, 21 Apr 1994 00:28:52 -0500 (CDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 936 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. As I know, the DOS TCP/IP stacks receive packets via the interrupt vector provided by packet drivers or shims. So that even the CPU is busy in running user programs, it's still possible to receive packets via interrupt. What about under Windows ? Is there any way to wake up the TCP/IP stacks to receive the incoming packets ? And because the TCP/IP stacks normally have some amount of buffer, user programs would not lose packets then. (if the incoming traffic is not too terrible) ,it would be nice if it's possible. thanks, Franklin. From natale@acec.com Wed Apr 20 22:20:42 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08205; Thu, 21 Apr 1994 10:26:27 -0400 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA21108 for rcq@ftp.com; Thu, 21 Apr 94 02:21:42 -0400 Date: Thu, 21 Apr 1994 02:20:42 -0400 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA21937; Thu, 21 Apr 1994 02:20:42 -0400 Message-Id: <9404210620.AA21937@nips.acec.com> To: rcq@ftp.com Subject: Re: closesocket()/WSACleanup() question Cc: winsock-hackers@sunsite.unc.edu > Date: Fri, 15 Apr 1994 22:22:51 -0400 > From: rcq@ftp.com (Bob Quinn) Hi BobQ, > graceful close. So, a DLL cannot be faulted if it resets the > connection when an application calls WSACleanup(), even if > closesocket() was called before. The application wouldn't > know the difference either way. > > My take on it is that if an application really cares about its > data and/or having a graceful close of the connection, then it > should wait until the socket is closed before calling WSACleanup(). > In other words, the onus should be on the application, not on the > WinSock DLL and stack. This is easily accomplished in an applica- > tion with FD_CLOSE notification, among other methods. > > Comments? Your position seems eminently reasonable to me. BobN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bob Natale American Computer 301-258-9850 [tel] Director 209 Perry Pkwy 301-921-0434 [fax] Network Mgmt Products Gaithersburg MD 20877 natale@acec.com From pbh@MIT.EDU Thu Apr 21 11:02:47 1994 Received: from MIT.EDU (MIT.MIT.EDU) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13851; Thu, 21 Apr 1994 11:02:47 -0400 Received: from ASHPOOL.MIT.EDU by MIT.EDU with SMTP id AA01502; Thu, 21 Apr 94 11:02:45 EDT Message-Id: <9404211502.AA01502@MIT.EDU> To: Multiple recipients of list Subject: WSAStartup() question Date: Thu, 21 Apr 94 11:02:44 From: pbh@MIT.EDU 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? From jobrien@mcs.umes.umd.edu Mon Apr 25 07:59:56 1994 Received: from umd5.umd.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10130; Mon, 25 Apr 1994 11:59:36 -0400 Received: from mcs.umes.umd.edu (umescsnw1.umd.edu [131.118.127.2]) by umd5.umd.edu(8.6.4/94Jan25) with SMTP id LAA27082; Mon, 25 Apr 1994 11:59:20 -0400 Received: from UMESCSNW1/MAILQUEUE by mcs.umes.umd.edu (Mercury 1.11); Mon, 25 Apr 94 12:00:41 EDT Received: from MAILQUEUE by UMESCSNW1 (Mercury 1.11); Mon, 25 Apr 94 12:00:01 EDT To: winsock-hackers@sunsite.unc.edu From: "James M. O'Brien, Jr" Organization: University of MD Eastern Shore Date: Mon, 25 Apr 1994 11:59:56 EDT Subject: FD_READ @ recv() Reply-To: jobrien@diver.umd.edu Priority: normal X-Mailer: WinPMail v1.0 (R2) Message-Id: <26C62214D48@mcs.umes.umd.edu> 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. What I've done so far is to test on bytes read using the following: case WM_WINSOCK : switch (WSAGETSELECTEVENT(lParam)) { case FD_READ : // Read Socket Data and Write it out if (ReadSocket(hMainEdit) == 0) { closesocket(sSocket); bCmdInProgress = FALSE; SendMessage(hWndMain,WM_SETCURSOR,hWndMain,0L); return 0; } .... Now this appears to work fine using Novell's TCP/IP & their winsock.dll. But it doesn't work correctly over Trumpet's winsock. I'll have to re-read the finger rfc, but I don't recall any explicit end of stream markers.. How would one handle this situation? Thanks - Jim O. From paul@atlas.dev.abccomp.oz.au Wed Apr 27 09:25:31 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19750; Wed, 27 Apr 1994 00:12:10 -0400 Received: by usage.csd.unsw.OZ.AU id AA11938 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 27 Apr 1994 14:11:59 +1000 Received: by atlas (4.1/1.35) id AA15057; Wed, 27 Apr 94 14:25:32 EST Message-Id: <9404270425.AA15057@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 27 Apr 1994 14:25:31 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: mmthomas@hpccoa.corp.hp.com, Multiple recipients of list Subject: Re: Unix to Winsock select() Thus expounded Markham Thomas on Apr 26, 6:22pm: /-------------------- | I have a problem with porting sockets code from an HP | 3000 and 9000 to the Winsock platform. In particular the problem | occurs on the select() statement. | The unix man pages for HP show the following as the definition | for the second parameter to select: (readfs is the variable) | | (option1) struct fd_set readmask, readfds; | | (option2) int readmask = 0; | int readfs; | | The HP systems will take either an int or a fd_set structure pointer as the |parameter. You would use the structure if the integer bit mask can't |hold the number of sockets you want to test. | The problem is that I wanted to have the same code (or prevent a major | rewrite) as that on the HP systems. It appears that the winsock.h header | file desires the structure pointer at the parm, and won't support an int. That's correct - the Winsock select() function only operates on an fd_set structure, because for Winsock an fd_set is implemented differently than in unix. In Winsock, an 'fd_set' is an array of sockets, with each one holding a possible socket handle, wheras in Unix the fd_set is a collection of integers constructing a bitmask, with each bit associated with a socket. This change had to be made because in Windows Sockets, the value of a 'socket' handle could be any possible value (except 0xFFFF), while under unix a 'socket handle' is a small integer (4,5,6 etc). The FD_SET, FD_CLR macros are also re-written so that, as long as your code uese these, the different underlying structure of the fd_set is transparent to the application. I still can't see your problem - code for the fd_set case at all times, and ignore the fact that HP unix will, in some cases, allow you to use an integer instead of an fd_set. -- 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 Apr 27 09:53:14 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA23736; Wed, 27 Apr 1994 00:40:45 -0400 Received: by usage.csd.unsw.OZ.AU id AA13120 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 27 Apr 1994 14:39:47 +1000 Received: by atlas (4.1/1.35) id AA15173; Wed, 27 Apr 94 14:53:15 EST Message-Id: <9404270453.AA15173@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 27 Apr 1994 14:53:14 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: FisherM@is3.indy.tce.com, Multiple recipients of list Subject: RE: DNS interface Thus expounded Fisher Mark on Apr 26, 6:46pm: /-------------------- | |To quote paul@atlas.abccomp.oz.au (">") and pbh@MIT.EDU ("|>"): |>|Most vendors already have res_mkquery() or the equivalent in their stacks |>|because it is used by the DNS support. Why don't we just make sure this |API |>|is exposed in the next release of the spec? |> |>Oh dear. Our internals don't use anything resembling res_mkquery() - can we |>take a straw-poll - which stacks _do_ have a res_mkquery(), whether |>accessable from outside the DLL or not, and which stacks don't? | |Furthermore (to betray my ignorance :)) is the DNS interface defined in an |RFC, or do you have to look at example code to figure it out? I have the |example code -- I'm just curious... There is no RFC that standardises the API for DNS, just as there is no RFC standardising an API for TCP/IP in general (these is no 'BSD sockets" RFC) - most people have copied the interface adopted by Unix popularised by BSD, known as "BSD Sockets", although many are moving to an alternative API called "TLI" - Transport Level Interface. The same, I guess, for the interface to DNS (which was added much later than the original 'BSD sockets' interface was codified), which for BSD was added because the original name resolution routines (gethostbyname etc) were designed for reading database files, not for dynamic server queries, and couldn't handle more generic DNS-specific queries like 'which server handles domain YYY' and 'who is in charge of the DNS for domain XXX'. |I do like the idea of a standard DLL for this. So do I - much more than forcing each vendor to implement a rarely used function like res_mkquery(), which is very DNS-specific. Not every stack, and I would guess in fact that very few stacks, actually implement their gethostbyYYY() calls as generic calls as an internal call to a 'res_mkquery' routine - certainly we manage quite well without one. The correct solution for a more generic DNS interface would be a DLL (that may well implement 'res_mkquery()') that creates the appropriate UDP datagrams and sockets, and does the query utilising the base SOCK_DGRAM capability of the generic Windows Sockets stack underneath. Then the single DLL could be used by everybody on top of everybody's stack, and only one person needs to invent the wheel. Cheers, -- 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 Apr 27 09:57:06 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24186; Wed, 27 Apr 1994 00:43:33 -0400 Received: by usage.csd.unsw.OZ.AU id AA13244 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 27 Apr 1994 14:43:40 +1000 Received: by atlas (4.1/1.35) id AA15202; Wed, 27 Apr 94 14:57:07 EST Message-Id: <9404270457.AA15202@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 27 Apr 1994 14:57:06 -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: FW: What's happening here? 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. -- 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 meunier@capsogeti.fr Wed Apr 27 10:50:03 1994 Received: from Relay1.OLEANE.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07478; Wed, 27 Apr 1994 02:51:58 -0400 Received: from csinn (csinn.cgs.fr [194.2.88.135]) by relay1.oleane.net (8.6.5/8.6.5) with SMTP id IAA22451 for ; Wed, 27 Apr 1994 08:51:54 +0200 X-Authentication-Warning: relay1.oleane.net: Host csinn.cgs.fr claimed to be csinn Received: from hercule by csinn (4.1/CSI2.2) id AA00307; Wed, 27 Apr 94 08:51:13 +0200 From: Jean-Luc Meunier Received: by hercule (AIX 3.2/UCB 5.64/CSI2.2) id AA17751; Wed, 27 Apr 1994 08:50:03 +0200 Date: Wed, 27 Apr 1994 08:50:03 +0200 Message-Id: <9404270650.AA17751@hercule> To: winsock-hackers@sunsite.unc.edu Subject: unsubscribe From cotrozzi@dsi.unimi.it Wed Apr 27 13:27:45 1994 Received: from pluto.sm.dsi.unimi.it (c700-3.sm.dsi.unimi.it) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA04623; Wed, 27 Apr 1994 06:28:49 -0400 Received: by pluto.From mmorse@nsf.gov Fri Apr 29 06:48:38 1994 Received: from z.nsf.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA04194; Fri, 29 Apr 1994 10:48:38 -0400 Received: from localhost (mmorse@localhost) by z.nsf.gov (8.6.4/8.6.4) id KAA11611; Fri, 29 Apr 1994 10:48:39 -0400 Message-Id: <199404291448.KAA11611@z.nsf.gov> From: mmorse@nsf.gov (Michael H. Morse) Date: Fri, 29 Apr 1994 10:48:38 EDT In-Reply-To: wilson@ftp.com (Brad Wilson) "Re: Trumpet WSK recvfrom()" (Apr 26, 8:42pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: wilson@ftp.com, Multiple recipients of list Subject: Re: Trumpet WSK recvfrom() > I believe both EasyWin and QuickWin (MS's counterpart) vehemently tell you > that you should not use calls to DLLs. Do you have any support for this statement? You may be right about the "should not", but the "vehemently" is definitely suspect. I have gone through the Borland 4.0 printed and on-line documentation and find no vehemence other that the following line: Note: EasyWin cannot be used with the DLL version of the run time library. Note that this doesn't say anything about using Winsock or other DLL's. Perhaps you're right, but I think a reference or two on your part would have been warranted to support your opinion. --Mike From leehart@microsoft.com Sat Apr 30 16:42:28 1994 Received: from netmail2.microsoft.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03538; Sat, 30 Apr 1994 16:42:28 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA15127; Sat, 30 Apr 94 12:43:23 -0700 From: leehart@microsoft.com Message-Id: <9404301943.AA15127@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Sat, 30 Apr 94 12:43:23 PDT X-Msmail-Message-Id: 81E05901 X-Msmail-Conversation-Id: 81E05901 To: dob@inel.gov, winsock-hackers@sunsite.unc.edu Date: Sat, 30 Apr 94 13:39:49 TZ Subject: RE: a redirecting DLL >From: >How does one go about making a redirecting DLL? For instance, if one had >the need to intercept all messages going to, say, WINSOCK.DLL, how would >you do this? >A simple example of such a DLL might be something that showed requests and >responses. This would be a kind of "pass through" DLL, not very involved >at all, and once it worked correctly it could be a great diagnostic tool, >among other things. >A little more involved DLL might be something that implemented one of the >proxy protocols, say SOCKS. With such a DLL all WinSock clients would >instantly become SOCKSified; well, in my dreams, of course, but it would >probably work well for the majority of clients. >If anyone can point me to some reference materials, or other helpful >information, I would certainly appreciate it. Also, if I developed it here >at work, I would try to make it freely available, like wslpd and WSGopher >are now. Chances are good that I'd succeed. If you know all entrypoints in the DLL you can use a method similar to what the parmprof tools in the Software Compatibility Test portion of the Win32 SDK for Windows NT do. You create a DLL (let's call it ZinSock.Dll) that has all of the public entrypoints of WinSock.Dll. Each of these functions will log the parameters (or do whatever) and then call the original API in WinSock.Dll. Then, for each .Exe or .Dll that you want to log you use the apfcnvrt.Exe tool from \sct\parmprof on the SDK CD to munge the import table from calling WinSock.Dll to call ZinSock.Dll instead. For example, D:\>apfcnvrt zinsock wormhole.exe WORMHOLE.EXE Imports: KERNEL GDI USER WINSOCK -> ZINSOCK SHELL Now, when this app runs it will call ZinSock.Dll instead of WinSock.Dll. The reason that you may not want to rename WinSock.Dll to something else is that then the module name of the renamed DLL will still be WINSOCK, which can cause problems. Lee Hart Not a spokesman for Microsoft From wilson@ftp.com Sat Apr 30 15:17:16 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA21710; Sat, 30 Apr 1994 19:17:25 -0400 Received: by ftp.com ; Sat, 30 Apr 1994 19:17:16 -0400 Received: by ftp.com ; Sat, 30 Apr 1994 19:17:16 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9404302317.AA09329@ftp.com> Subject: Re: a redirecting DLL To: dob@inel.gov Date: Sat, 30 Apr 1994 19:17:16 -0400 (EDT) Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9404192150.AA18762@dewey.inel.gov> from "dob@inel.gov" at Apr 30, 94 12:30:23 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: 1978 >> How does one go about making a redirecting DLL? For instance, if one had >> the need to intercept all messages going to, say, WINSOCK.DLL, how would >> you do this? The probable implementation would be non-trivial. You would need to create a WINSOCK.DLL that is standard, rename the old winsock to something like (_WINSOCK.DLL) as well as modify the old WINSOCK's module name in the executable to match (otherwise, you would have module name clashes). Since this does some pretty evil things that you would need to undo if the user wanted to remove your changes, you should really think twice about doing it. It should work, though... >> A simple example of such a DLL might be something that showed requests and >> responses. This would be a kind of "pass through" DLL, not very involved >> at all, and once it worked correctly it could be a great diagnostic tool, >> among other things. Boundschecker for Windows takes an interesting twist on this. When it loads the executable that it'll be checking, it does in memory changes of the dynamic linking, so that all API calls are routed through the DLL that makes sure all your calls are okay. This also is not very trivial and just a little bit more evil. >> A little more involved DLL might be something that implemented one of the >> proxy protocols, say SOCKS. With such a DLL all WinSock clients would >> instantly become SOCKSified; well, in my dreams, of course, but it would >> probably work well for the majority of clients. It would seem to make sense to ask your vendor to provide these things in your stack (or perhaps your apps vendor...). Good luck ... and don't forget to write an uninstall! ;-) -- 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