From dboone@zeus.fasttax.com Wed Mar 2 13:36:52 1994 Received: from zeus.fasttax.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18142; Wed, 2 Mar 1994 20:38:15 -0500 Received: by zeus.fasttax.com (5.67/1.37) id AA04256; Wed, 2 Mar 94 19:37:52 -0601 Date: Wed, 2 Mar 94 19:37:52 -0601 From: dboone@zeus.fasttax.com (Doug Boone 7993) Message-Id: <9403030138.AA04256@zeus.fasttax.com> To: winsock-hackers@sunsite.unc.edu From johnt@unipalm.co.uk Thu Mar 3 17:38:30 1994 Received: from unipalm.co.uk (unipalm.unipalm.co.uk) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA27587; Thu, 3 Mar 1994 12:35:30 -0500 Received: from brimstone.unipalm.co.uk by unipalm.co.uk (4.1/SMI-4.1 (unipalm 1.17)) id AA17783; Thu, 3 Mar 94 17:33:39 GMT Received: from dreft.unipalm.co.uk by brimstone.unipalm.co.uk (4.1/SMI-4.1 brimstone 1.19) id AA08046; Thu, 3 Mar 94 17:31:39 GMT Message-Id: <9403031731.AA08046@brimstone.unipalm.co.uk> Priority: Urgent To: winsock-hackers@sunsite.unc.edu Reply-To: johnt@unipalm.co.uk Mime-Version: 1.0 From: John Taylor Subject: What causes EDESTADDREQ ? Date: Thu, 03 Mar 94 17:38:30 GMT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"; X-MAPIrenderingpos=0xFFFFFFFF Content-Transfer-Encoding: quoted-printable Hi, Is this list still active ? I've not seen anything for ages. I have been getting occasional errors when calling connect(). I get WSAEDESTADDREQ returned. I get the same error on a couple of different stacks, so it must = be something I'm doing. Any ideas what it means ? Thanks John Taylor johnt@unipalm.co.uk From heathh@ugcs.caltech.edu Thu Mar 3 02:16:24 1994 Received: from envy.ugcs.caltech.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA04033; Thu, 3 Mar 1994 13:16:32 -0500 Received: from gluttony.ugcs.caltech.edu by envy.ugcs.caltech.edu with SMTP (1.37.109.8/UGCS:4.42) id AA28849; Thu, 3 Mar 1994 10:16:29 -0800 From: heathh@ugcs.caltech.edu (Heath I Hunnicutt) Received: by gluttony.ugcs.caltech.edu (1.37.109.8/UGCS:4.42) id AA04421; Thu, 3 Mar 1994 10:16:25 -0800 Message-Id: <9403031816.AA04421@gluttony.ugcs.caltech.edu> Subject: Re: What causes EDESTADDREQ ? To: winsock-hackers@sunsite.unc.edu Date: Thu, 3 Mar 1994 10:16:24 -0800 (PST) In-Reply-To: <9403031731.AA08046@brimstone.unipalm.co.uk> from "John Taylor" at Mar 3, 94 01:00:51 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 672 > Is this list still active ? I'm new to it, so I cannot say. > I have been getting occasional errors when calling connect(). > I get WSAEDESTADDREQ returned. > > I get the same error on a couple of different stacks, so it must = > be something I'm doing. The error means you did not give a valid address to connect to. In fact, it probably means you gave IPADDR_NONE. This could be cause by (perhaps) using inet_ntoa() and not checking the return, then passing that to connect(). Anyway, try adding some debug code that dumps out the structure you pass to connect, and see if you can determine what sort of invalid address you are giving it. Good luck, Heath From beame@ns.bws.com Thu Mar 3 08:45:12 1994 Received: from ns.bws.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12274; Thu, 3 Mar 1994 13:45:08 -0500 Received: from carl.bws.com by ns.bws.com (AIX 3.1/UCB 5.61/4.03) id AA07243; Thu, 3 Mar 94 13:45:10 -0500 To: winsock-hackers@sunsite.unc.edu, johnt@unipalm.co.uk From: Carl Beame Cc: beame@ns.bws.com Sender: beame@ns.bws.com Subject: Re: What causes EDESTADDREQ ? X-Originating-Host: carl.bws.com Reply-To: beame@ns.bws.com In-Reply-To: <9403031731.AA08046@brimstone.unipalm.co.uk> Message-Id: <1994Mar03.134512-0500@carl.bws.com> Date: 03 Mar 1994 13:45:12 -0500 X-Mailer: BWMail for Windows Version 3.0c In <9403031731.AA08046@brimstone.unipalm.co.uk>, John Taylor wrote: >Hi, >Is this list still active ? > >I've not seen anything for ages. > >I have been getting occasional errors when calling connect(). >I get WSAEDESTADDREQ returned. > >I get the same error on a couple of different stacks, so it must = >be something I'm doing. > >Any ideas what it means ? > The only time our stack (B&W) returns this error is if a UDP send/sendto is done with the destination address equal to NULL and the socket has not been connected. -- Carl Beame Beame & Whiteside Software beame@bws.com (voice) +1 (919) 831-8989 (fax) +1 (919) 831-8990 From Benjamin.Youngdahl@pigeon.cpg.cdc.com Thu Mar 3 09:50:34 1994 Received: from zeus.cdc.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA22343; Thu, 3 Mar 1994 17:35:45 -0500 Received: from pigeon2.cpg.cdc.com by zeus.cdc.com; Thu, 3 Mar 94 15:51:43 -0600 Date: 3 Mar 1994 15:50:34 -0600 From: "Benjamin Youngdahl" Subject: subscribe To: " " Message-Id: <2d765bef2601002@zeus.cdc.com> GatorMail-Q subscribe *sigh* . Sorry, I meant to send my previous subscription message to "listserv" not "winsock-hackers". Please hold back flames. From Benjamin.Youngdahl@pigeon.cpg.cdc.com Thu Mar 3 09:47:52 1994 Received: from zeus.cdc.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA22389; Thu, 3 Mar 1994 17:35:56 -0500 Received: from pigeon2.cpg.cdc.com by zeus.cdc.com; Thu, 3 Mar 94 15:51:51 -0600 Date: 3 Mar 1994 15:47:52 -0600 From: "Benjamin Youngdahl" Subject: subscribe To: " " Message-Id: <2d765bf72631002@zeus.cdc.com> GatorMail-Q subscribe subscribe winsock-hackers Ben.Youngdahl@cdc.com From warrent@bnr.ca Thu Mar 3 13:46:00 1994 Received: from bnr.ca (x400gate.bnr.ca) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25432; Thu, 3 Mar 1994 17:55:52 -0500 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Mar 1994 17:25:47 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Mar 1994 13:46:28 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 3 Mar 1994 08:46:00 -0500 Date: Thu, 3 Mar 1994 13:46:00 +0000 X400-Originator: /dd.id=155285/g=warren/i=w/s=thompson/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.697:03.02.94.18.46.28] X400-Content-Type: P2-1984 (2) Content-Identifier: re:What cause... From: "warren (w.) thompson" Sender: "warren (w.) thompson" Message-Id: <"23582 Thu Mar 3 14:28:39 1994"@bnr.ca> To: winsock-hackers@sunsite.unc.edu Subject: re:What causes EDESTADDREQ ? In message "What causes EDESTADDREQ ?", you write: > Hi, > Is this list still active ? > > I've not seen anything for ages. Yours was the first message I have received since February 8. I was starting to wonder the same thing. Regards, Warren Thompson work: warrent@bnr.ca play: warren.thompson@canrem.com From ZANNA%LABEN@icil64.cilea.it Fri Mar 4 03:07:34 1994 Received: from icil64.cilea.it ([131.175.1.5]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA02421; Fri, 4 Mar 1994 03:07:34 -0500 Received: from DECNET-MAIL (ZANNA@LABEN) by ICIL64.CILEA.IT (PMDF V4.2-14 #2920) id <01H9KHAEOTS099DPH1@ICIL64.CILEA.IT>; Fri, 4 Mar 1994 09:07:14 MET-DST Date: Fri, 4 Mar 1994 09:07:14 MET-DST From: "A.ZANNA" Subject: Trumpet WSK recvfrom() To: winsock-hackers@sunsite.unc.edu Message-Id: <01H9KHAEQ60I99DPH1@ICIL64.CILEA.IT> X-Vms-To: ICIL64::IN%"winsock-hackers@sunsite.unc.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Hallo to everyone on the list. I'm evaluating Trumpet winsock as a platform for some in-house programs. I quickly ported some trivial code samples from UNIX that I could easily adapt to compile and run in BORLAND C++ EasyWin stdio consoles. All samples ported and worked fine, EXCEPT for the one that calls recvfrom(). I get instant GPF when I call this. I'm pretty confident the code is OK (worked on UNIX, works when I use recv rather than recvfrom(), structs are OK...) What I'm planning to write requires use of recvfrom(), so I'm stuck. I first blamed it on Trumpet A18, but I just downloaded Trumpet 1 and it blows up just the same. Unfortunately, I can't try my code on another winsock stack. Has anybody gotten recvfrom() to work on Trumpet winsock? Thanks for any clues, Andy ------------------ Andy Zanna SW R&D, LABEN, Italy ZANNA%LABEN@icil64.cilea.it From tonyh@tonyspc.demon.co.uk Fri Mar 4 14:53:42 1994 Received: from tonyspc.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA23185; Fri, 4 Mar 1994 09:58:34 -0500 Date: Fri, 04 Mar 94 14:53:42 GMT Message-Id: <3342415@tonyspc.demon.co.uk> From: tonyh@tonyspc.demon.co.uk (Tony Hill) Reply-To: tonyh@tonyspc.demon.co.uk To: winsock-hackers@sunsite.unc.edu Subject: subscribe winsock-hackers tonyh@tonyspc.demon.co.uk X-Mailer: PCElm 1.08 Lines: 3 -- Tony Hill From wilson@ftp.com Fri Mar 4 10:12:37 1994 Received: from ftp.com ([128.127.2.122]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA02324; Fri, 4 Mar 1994 15:14:39 -0500 Received: by ftp.com ; Fri, 4 Mar 1994 15:12:38 -0500 From: wilson@ftp.com (Brad Wilson) Message-Id: <9403042012.AA21219@ftp.com> Subject: Re: Trumpet WSK recvfrom() To: ZANNA%LABEN@icil64.cilea.it Date: Fri, 4 Mar 1994 15:12:37 -0500 (EST) Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <01H9KHAEQ60I99DPH1@ICIL64.CILEA.IT> from "A.ZANNA" at Mar 4, 94 03:08:24 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 608 >> I could easily adapt to compile and run in BORLAND C++ EasyWin stdio >> consoles. I believe both EasyWin and QuickWin (MS's counterpart) vehemently tell you that you should not use calls to DLLs. I would suggest writing a real Windows app to do what you want to do, and making sure the call works from there. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet Email: wilson@ftp.com "A little government and a little luck are necessary in life, but only a fool trusts either of them." -P.J. O'Rourke From richard%locomotive.com@locosoft.demon.co.uk Mon Mar 7 14:49:27 1994 Received: from gate.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA06341; Mon, 7 Mar 1994 15:22:50 -0500 Received: from locosoft.demon.co.uk by gate.demon.co.uk id aa25325; 7 Mar 94 18:53 GMT Date: Mon, 07 Mar 94 14:49:27 GMT From: Richard Clayton Reply-To: richard@locomotive.com Message-Id: <2184@locomotive.com> To: winsock-hackers@sunsite.unc.edu Subject: Is the Ioctlsocket(SIOCATMARK) result a BOOL? X-Mailer: PCElm 1.09 Lines: 31 Fellow Hackers, I hope this fits within the remit of this list. Ioctlsocket(s, SIOCATMARK, argp) is documented that the argument is "u_long FAR *". The description states that argp is a pointer to a BOOL ie it's a 4 byte pointer but to a 2 byte BOOL not a 4 byte u_long. Does this mean that the Trumpet Winsock (1.0 Rev A) is incorrect in setting a FOUR byte area (to zero or one) ?? Or is the spec misleading in stating that a u_long FAR * points to a BOOL ?? [[ or to put it another way, do I report the problem to Tasmania, or to the authors of the spec? ]] Do any other stacks think that BOOLs are 4 bytes? (It took me a while to track down who'd zeroized the variable next door to my BOOL! The code is robust now, but I think this needs clearing up.) This is clearly a rather messy area. FIONBIO takes a proper u_long as an argument (though it only needs a BOOL). Comes of copying BSD I suppose. Interpretations welcomed! richard ------------------------------------------------------------------------- Richard Clayton, Locomotive Software tel: +44 306 740606 Dorking Business Park, DORKING, Surrey, UK. RH4 1YL fax: +44 306 885529 "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM From natale@acec.com Mon Mar 7 13:51:01 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11714; Mon, 7 Mar 1994 18:52:31 -0500 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14426 for winsock-hackers@sunsite.unc.edu; Mon, 7 Mar 94 18:52:08 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA19569; Mon, 7 Mar 1994 18:51:18 -0500 Date: Mon, 7 Mar 1994 18:51:01 EST From: Bob Natale Subject: Does "initially" mean anything? To: winsock-hackers@sunsite.unc.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/Plain; CHARSET=US-ASCII Well, since everyone's been lamenting the lack of traffic on this list, here's an easy one to just see if the road is still open: On p. 91 of the MS-Word print-out of the v1.1 WinSock spec, wrt the posting of WSAAsyncSelect() notification messages, it says: "If an event is true when the application initially calls WSAAsyncSelect() or when the reenabling function is called, then a message is posted as appropriate." My main question is: Is the word "initially" there on purpose? If so, does it imply that a subsequent call to WSAAsyncSelect does not or might not trigger the same behavior? Or is "initially" in there just to emphasize that if a certain state arises before the app has a chance to WSAAsyncSelect(), it will nonetheless be notified? One possibly quirky thing we _thing_ we have observed is that doing multiple WSAAsyncSelect() calls _seems_ to cause us to _lose_ notifications. For example, say we're watching for incoming UDP packets. We post an initial WSAAsyncSelect() for FD_READ and eventually get notified that a packet has arrived. Being UDP, we can read the whole packet in one recv() operation. Nonetheless, before we process the FD_READ maybe additional packets arrive too (with further FD_READ notifications because we have not yet called the reenabling function). Now we read the first packet and follow that up with a[nother, redundant] WSAAsyncSelect() call for FD_READ notification. Can we then expect to get a more or less immediate FD_READ notification for the packets that were already in our queue and covered by an earlier FD_READ notification and a call to the reenabling recv() function? Or does the new WSAAsyncSelect() call start from the point it is called? Just curious. We have found that, with the WinSock implementation we are using at least, removing the unnecessary WSAAsyncSelect() calls--which we are happy to do just on general principle!--causes our app to behave propoerly...whereas using the extraneous WSAAsyncSelect() calls caused anomalous behavior ("lock up"). Any comments, explanations, tutorials, or questions will be appreicated. Thanks. BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com From natale@acec.com Mon Mar 7 20:15:05 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24845; Tue, 8 Mar 1994 01:16:43 -0500 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06531 for winsock-hackers@sunsite.unc.edu; Tue, 8 Mar 94 01:16:18 -0500 Date: Tue, 8 Mar 1994 01:15:05 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA00554; Tue, 8 Mar 1994 01:15:05 -0500 Message-Id: <9403080615.AA00554@nips.acec.com> To: winsock-hackers@sunsite.unc.edu Subject: Important Typo in Earlier Message :-{{{{ Cc: abraham@acec.com, gandin@acec.com 'Twas too close to dinner and all thru the house... Sorry for this little mess, folks, but on my query about the meaning of "initially" in the WSAAsyncSelect() description, I left out one pretty important little word: > Date: Mon, 7 Mar 1994 22:07:36 -0500 > From: Bob Natale > Subject: Does "initially" mean anything? > > Being UDP, we can read the whole packet in one recv() operation. > Nonetheless, before we process the FD_READ maybe additional > packets arrive too (with further FD_READ notifications because ---------------------->>> ^ "NO" > we have not yet called the reenabling function). Now we read Not sure if the question makes more sense with or without it, but, hey, you hackers are supposed to be gritty gritters! :-) Thanks for giving this some thought and letting me know if you see anything significant. 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 rcq@mailserv-D.ftp.com Mon Mar 7 21:55:56 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05849; Tue, 8 Mar 1994 02:57:12 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 8 Mar 1994 02:56:30 -0500 Received: from rcq.aeolus.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA00851; Tue, 8 Mar 94 02:55:56 EST Date: Tue, 8 Mar 94 02:55:56 EST Message-Id: <9403080755.AA00851@mailserv-D.ftp.com> To: natale@acec.com Subject: Re: Does "initially" mean anything? 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 Tue Mar 8 02:55:37 1994] Originating-Client: aeolus.ftp.com Content-Length: 2920 > On p. 91 of the MS-Word print-out of the v1.1 WinSock spec, wrt > the posting of WSAAsyncSelect() notification messages, it says: > > "If an event is true when the application initially > calls WSAAsyncSelect() or when the reenabling function > is called, then a message is posted as appropriate." > > My main question is: Is the word "initially" there on purpose? Yes. It means that at the time you call WSAAsynchSelect(), if the condition is true then notification is sent. It doesn't matter how many times you call WSAAsynchSelect(). Each time its called, it generates notification. In other words, it reports on the "state" of a socket, as well as an asynch event. That's part of what "level triggered" means. > One possibly quirky thing we _thing_ we have observed is that > doing multiple WSAAsyncSelect() calls _seems_ to cause us to > _lose_ notifications. For example, say we're watching for > incoming UDP packets. We post an initial WSAAsyncSelect() for > FD_READ and eventually get notified that a packet has arrived. > Being UDP, we can read the whole packet in one recv() operation. > Nonetheless, before we process the FD_READ maybe additional > packets arrive too (with further FD_READ notifications because > we have not yet called the reenabling function). OOOPS. You should *NOT* be getting the "further FD_READ notifi- cations" if you haven't yet called the reenabling function (recv() or recvfrom()). You haven't reenabled notification. > Now we read > the first packet and follow that up with a[nother, redundant] > WSAAsyncSelect() call for FD_READ notification. Why? This is the cause of your woes. > Can we then > expect to get a more or less immediate FD_READ notification for > the packets that were already in our queue and covered by an > earlier FD_READ notification and a call to the reenabling recv() Yes. Expect TWO, in fact. One from after your call to recv() or recvfrom() if you have any more datagrams queued for reading, and the second one from the WSAAsyncSelect() call indicating you "initially" have data to read. > function? Or does the new WSAAsyncSelect() call start from the > point it is called? Just curious. No. > We have found that, with the WinSock implementation we are using > at least, removing the unnecessary WSAAsyncSelect() calls--which > we are happy to do just on general principle!--causes our app to > behave propoerly...whereas using the extraneous WSAAsyncSelect() > calls caused anomalous behavior ("lock up"). Yes. This makes sense. The extra WSAAsyncSelect() calls should cause extra read notifications. These would certainly confuse any application, by making it think it's getting data that really isn't there. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From hille@rz.informatik.uni-hamburg.d400.de Tue Mar 8 13:12:29 1994 Received: from ixgate02.dfnrelay.d400.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19477; Tue, 8 Mar 1994 06:13:34 -0500 X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Tue, 8 Mar 1994 12:14:08 +0100 X400-Received: by /PRMD=uni-hamburg/ADMD=d400/C=de/; Relayed; Tue, 8 Mar 1994 12:12:29 +0100 Date: Tue, 8 Mar 1994 12:12:29 +0100 X400-Originator: hille@rz.informatik.uni-hamburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uni-hamburg/ADMD=d400/C=de/;940308121229] X400-Content-Type: P2-1984 (2) Content-Identifier: 281 Alternate-Recipient: Allowed From: Gunter Message-Id: <281*/S=hille/OU=rz/OU=informatik/PRMD=uni-hamburg/ADMD=d400/C=de/@MHS> To: winsock-hackers@sunsite.unc.edu (Non Receipt Notification Requested) Subject: WSAASyncSelect() reenabling I experienced problems with the asynchronous sending. When using different stacks, Trumpet (beta 1.0a) needs another WSAAsyncSelect() or it will hang. Netmanage (demo version of Jan 93) does not need another call to WSAASyncSelect(). What is the correct action if the WSAEWOULBLOCK error appears while sending asynchronously. Do I need to call select() before sending? A piece of code would be nice to see how other authors solved this. Gunter From natale@acec.com Tue Mar 8 05:22:01 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13456; Tue, 8 Mar 1994 10:24:15 -0500 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17626 for winsock-hackers@sunsite.unc.edu; Tue, 8 Mar 94 10:23:32 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA02062; Tue, 8 Mar 1994 10:22:23 -0500 Date: Tue, 8 Mar 1994 10:22:01 EST From: Bob Natale Subject: Re: WSAASyncSelect() reenabling To: hille@rz.informatik.uni-hamburg.d400.de Cc: Multiple recipients of list Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/Plain; CHARSET=US-ASCII > From: Gunter > Date: Tue, 8 Mar 1994 06:27:03 -0500 Hi Gunter, > I experienced problems with the asynchronous sending. When using different > stacks, Trumpet (beta 1.0a) needs another WSAAsyncSelect() or it will hang. > Netmanage (demo version of Jan 93) does not need another call to > WSAASyncSelect(). > > What is the correct action if the WSAEWOULBLOCK error appears while sending > asynchronously. Do I need to call select() before sending? A piece of code > would be nice to see how other authors solved this. Well, this is still fresh in my mind from p. 91 of the spec (as I am addressing a similar problem on another thread). In the case you descirbe, assuming you have posted a WSAAsyncSelect() for FD_WRITE, and you receive an FD_WRITE, and you start to send, and you then (eventually) receive a WSAEWOULDBLOCK, then you should receive another FD_WRITE (without needing another WSAAsyncSelect() for it) _when_ "buffer space becomes available". I think that is very clear from the paragraph on FD_WRITE behavior on p. 91. So it sounds to me, based just on your description above, that the NetManage implementation is behaving correctly and Trumpet is not. I'd like to know if others interpret this differently. Regards, BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com From richard@locomotive.com Tue Mar 8 09:57:07 1994 Received: from locosoft.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15633; Tue, 8 Mar 1994 10:39:00 -0500 Date: Tue, 08 Mar 94 09:57:07 GMT From: richard@locomotive.com (Richard Clayton) Reply-To: richard@locomotive.com Message-Id: <2213@locomotive.com> To: natale@acec.com, winsock-hackers@sunsite.unc.edu Subject: Re: Does "initially" mean anything? X-Mailer: PCElm 1.09 Lines: 45 In message natale@acec.com writes: > "If an event is true when the application initially > calls WSAAsyncSelect() or when the reenabling function > is called, then a message is posted as appropriate." > > My main question is: Is the word "initially" there on purpose? > If so, does it imply that a subsequent call to WSAAsyncSelect > does not or might not trigger the same behavior? Or is "initially" > in there just to emphasize that if a certain state arises before > the app has a chance to WSAAsyncSelect(), it will nonetheless > be notified? I have a standard "connnection" dialog box which just "arms" FD_CONNECT. This message then goes to an appropriate handler which arms FD_READ, FD_WRITE etc as needed for the particular connection I have in mind. If the first WSAAsyncSelect() has to arm all possible events then this will be much messier to implement. > One possibly quirky thing we _thing_ we have observed is that > doing multiple WSAAsyncSelect() calls _seems_ to cause us to > _lose_ notifications. Again, consider a Telnet session. FD_READ needs to be permanently "armed", but one might only arm FD_WRITE when one was unable to send - but you would leave FD_READ armed as well. If this lost you an FD_READ event then this would be very sad indeed. If instead you arm FD_READ|FD_WRITE initially then you will be continually handling totally useless FD_WRITE events (useless because you have nothing further to send most of the time). I agree that the word "initially" seems on a legalistic reading to permit this loss-of-event behaviour, but it is such a nuisance to program around that (IMHO) the stack should be considered broken! Please name it so that it can be avoided! richard ------------------------------------------------------------------------- Richard Clayton, Locomotive Software tel: +44 306 740606 Dorking Business Park, DORKING, Surrey, UK. RH4 1YL fax: +44 306 885529 "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM From marke@firefox.co.uk Tue Mar 8 16:58:58 1994 Received: from relay2.pipex.net by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA29980; Tue, 8 Mar 1994 12:10:17 -0500 Received: from FFSCO.firefox.co.uk by relay2.pipex.net with SMTP (PP) id <18707-0@relay2.pipex.net>; Tue, 8 Mar 1994 17:10:12 +0000 From: Mark Edwards X-Mailer: SCO System V Mail (version 3.2) To: winsock-hackers@sunsite.unc.edu Subject: Re: Re: WSAAsyncSelect() reenab Date: Tue, 8 Mar 94 16:58:58 gmt Message-Id: <9403081659.aa07735@ffsco.firefox.co.uk> Bob, Gunter et al, My understanding is that once a WSAAsyncSelect() with sets the FD_WRITE then until another WSAAsyncSelect() alters the behaviour, the send() should work as follows. The send() function takes user data and buffers/writes the data to the TCP/IP stack. If there is any send data buffer space still available after the current user buffer is processed then you will receive an FD_WRITE. If on the other hand you get a WSAEWOULDBLOCK from the send(), then the moment that the stack frees up any buffer space (albeit only 1 byte) the code should give you an FD_WRITE. I think that concurs with Bob's interpretation. I would consider any stack deviating from that to be 'suspect'. The objective in using WSAAsyncSelect() is that it need only be called once (or each time the socket profile needs changing) and thereafter the DLL does all the work for you by posting messages at the appropriate time. It cuts out all that tedious looping required to call select(). Regards. Mark. ---------------------------------------------------------- Mark S. Edwards Firefox Communications Ltd, Cranmore House, Cranmore Boulevard, Solihull, West Midlands. United Kingdom. B90 4RX. phone : 021 609 6090 (intl, 44 21 609 6090) Fax : 021 609 6060 (intl, 44 21 609 6060) Internet: marke@firefox.co.uk ----------------------------------------------------------  From william@sybase.com Tue Mar 8 03:26:09 1994 Received: from halon.sybase.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25872; Tue, 8 Mar 1994 15:05:49 -0500 Received: from sybase.com (sybgate.sybase.com) by halon.sybase.com (5.0/SMI-SVR4/SybFW4.0) id AA10271; Tue, 8 Mar 94 11:28:38 PST Received: from mercury.sybgate.sybase.com (mercury-1) by sybase.com (4.1/SMI-4.1/SybH3.3) id AA22977; Tue, 8 Mar 94 11:26:08 PST Received: by mercury.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.2) id AA03239; Tue, 8 Mar 94 11:26:10 PST From: william@sybase.com (William Wong) Message-Id: <9403081926.AA03239@mercury.sybgate.sybase.com> Subject: Yielding to other apps in Winsock To: winsock-hackers@SunSITE.Unc.EDU Date: Tue, 8 Mar 94 11:26:09 PST Cc: william@sybase.com (William Wong) X-Mailer: ELM [version 2.3 PL0] Content-Length: 0 Hi Fellow Winsock hackers, I have a Winsock question relating to improve the responsiveness to the user in Windows. I found out that using straight async read/write is no better than using blocking read/write. I have a Winsock application that does background data transfer as one of its tasks. Trying to be courteous and not hogging Windows, I use async read/write with WSAAsyncSelect(). I thought WSAAsyncSelect() supposes to take care of letting-other-apps-to-breath issue. However, even when I use async read and write, my application still hogs Windows in large transfers. In a >500K transfer, I can only "doing some other things" in Windows once every 10 seconds. "Doing some other things" involves merely switching applications. This is behaving just like the blocking read/write. Here is my feeling on the problem. Data comes in. WSAAsyncSelect() places a FD_READ in my app's message queue. I do a recv(). Suppose the data keeps coming in. Recv() will re-enable and place another FD_READ in my app's message queue. My app finishes handling the old FD_READ and exits the handler function and returns control back to Windows. Windows sees there are still message sin my queue. It will not switch to other apps. It will dispatch those messages to my message handler. I do a recv(), and starts the whole cycle again. Now if the data comes in fast enough, control will rarely leave my app until I read all the data. This is no better than the blocking read. At least in blocking read, the winsock stack does the yield occasionally. It looks like the PeekMessage() loop approach is unavoidable. Ugh, ugly re-entrance problem. So do I have to have my own PeekMessage() loop even when I am using async read/write? What do you people think? William ---- william@sybase.com From rcq@mailserv-D.ftp.com Tue Mar 8 11:03:41 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05795; Tue, 8 Mar 1994 16:06:07 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 8 Mar 1994 16:04:11 -0500 Received: from rcq.aeolus.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08580; Tue, 8 Mar 94 16:03:41 EST Date: Tue, 8 Mar 94 16:03:41 EST Message-Id: <9403082103.AA08580@mailserv-D.ftp.com> To: richard@locomotive.com Subject: Re: Does "initially" mean anything? 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 Tue Mar 8 16:03:32 1994] Originating-Client: aeolus.ftp.com Content-Length: 2669 > I have a standard "connnection" dialog box which just "arms" > FD_CONNECT. This message then goes to an appropriate handler > which arms FD_READ, FD_WRITE etc as needed for the particular > connection I have in mind. > > If the first WSAAsyncSelect() has to arm all possible events > then this will be much messier to implement. Each WSAAsyncSelect() call supercedes the previous call(s), or in the language of the spec: "issuing a WSAAsyncSelect() for a socket cancels any previous WSAAsynchSelect()." This means that your strategy of "arming" events as needed is fine; it arms for events appropriate to the current state of the socket/connection. Although, let me point out that requesting all the events you need up front is usually *less* messy to implement, since you're not calling WSAAsyncSelect() more than once. The only extra message you'd have to handle is the FD_WRITE upon connection (which you won't need unless your application sends first). > > One possibly quirky thing we _thing_ we have observed is that > > doing multiple WSAAsyncSelect() calls _seems_ to cause us to > > _lose_ notifications. > > Again, consider a Telnet session. FD_READ needs to be permanently > "armed", but one might only arm FD_WRITE when one was unable to > send - but you would leave FD_READ armed as well. If this lost > you an FD_READ event then this would be very sad indeed. Arming FD_WRITE when one is unable to send is a bad idea. This will generate more messages and confuse the application, as Bob experienced. Besides this, it's extra work that the FD_WRITE event was designed precisely to avoid. > If instead you arm FD_READ|FD_WRITE initially then you will > be continually handling totally useless FD_WRITE events (useless > because you have nothing further to send most of the time). No, you won't. You only get an FD_WRITE message 1) after an initial connection and 2) after a send() has failed with an WSAEWOULDBLOCK error, and buffer space has subsequently become available (so the chance is you can reliably send when an FD_WRITE is received ...though there's no guarantee). > I agree that the word "initially" seems on a legalistic reading > to permit this loss-of-event behaviour, but it is such a nuisance > to program around that (IMHO) the stack should be considered broken! Perhaps it should be re-written given the confusion evidenced, but it is valid. It refers to when WSAAsyncSelect() is called, anytime it's called (i.e. not just the first time it's called). Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From stcheng@eemips.tamu.edu Tue Mar 8 11:48:25 1994 Received: from EEMIPS.TAMU.EDU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01301; Tue, 8 Mar 1994 18:47:17 -0500 Received: by eemips.tamu.edu (5.61/1.34) id AA27711; Tue, 8 Mar 94 17:48:26 -0600 From: stcheng@eemips.tamu.edu (Franklin S. Cheng) Message-Id: <9403082348.AA27711@eemips.tamu.edu> Subject: multicast IP To: winsock-hackers@sunsite.unc.edu (WINSOCK) Date: Tue, 8 Mar 1994 17:48:25 -0600 (CST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 174 Fellow hackers, I've heard PC/TCP V2.3 supports multicast IP. Does anyone out there know if the incoming Winsock v2.0 spec will support multicast IP ? thanx, --Franklin From johnston@hookup.net Tue Mar 8 14:52:29 1994 Received: from nic.hookup.net by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10000; Tue, 8 Mar 1994 19:54:12 -0500 Received: from johnston.hookup.net (johnston.hookup.net [198.133.162.148]) by nic.hookup.net (8.6.6.Beta11/1.120) with SMTP id TAA06011; Tue, 8 Mar 1994 19:54:06 -0500 Message-Id: <199403090054.TAA06011@nic.hookup.net> X-Sender: johnston@hookup.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Mar 1994 19:52:29 -0500 To: winsock-hackers@SunSITE.Unc.EDU From: johnston@hookup.net (Stewart Johnston) Subject: Help Winsock over SLIP ! X-Mailer: Help Winsock over SLIP ! I'm trying to set up a WinSock Client and Server over a slip connection, but its not working. The Setup: - Two 386s connected via serial ports. - No dialup , no hardware handshake - Both running - Trumpet Winsock 1.0 Rev A - TCPMAN .exe - Client - Mfinger.exe from { sunsite.unc.edu } - COM3 , 2400 BAUD. - Trumpet Winsock IP address = 198.133.162.148 Name server= 198.133.162.1 { I don't think there is a name server} Time server= 0.0.0.0 Domain Suffix = left blank MTU = 512 TCP RWIN = 1448 TCP MSS = 552 Packet vector = 00 Demand Load Timeout = 5 Internal SLIP = yes SLIP Port = 3 Baud Rate = 2400 Hardware Handshake = no CSLIP = yes On line status detection = none On the other computer. - Server - txtsrv.exe from { sunsite.unc.edu } - A txt server - claims it will respond to the finger protocol - COM2 , 2400 BAUD. - Trumpet Winsock IP address = 198.133.162.149 Name server= 198.133.162.1 Time server= 0.0.0.0 Domain Suffix = left blank MTU = 512 TCP RWIN = 1448 TCP MSS = 552 Packet vector = 00 Demand Load Timeout = 5 Internal SLIP = yes SLIP Port = 2 Baud Rate = 2400 Hardware Handshake = no CSLIP = yes On line status detection = none Proceedure - on both computers I fire up tcpman.exe ( no problems) - then I fire up ( txtsrv ) and (mfinger ) on their separate computers. ( no problems ) - then with mfinger I try to finger the server. - In mfinger's HOST dialog box I enter: " 198.133.162.149 " ( the servers IP ) - mfinger responds: " cannot locate port for finger " I have been monitoring the serial line and there doesnot seem the be any activity. So my quess is that winsock is not talking to the serial port. shouldn't it at least send some characters over the serial port to the server. What am I doing wrong? Please help. Thanks Stewart Johnston johnston@hookup.net From dave@auspost.com.au Wed Mar 9 22:52:29 1994 Received: from yarrina.connect.com.au by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA17190; Tue, 8 Mar 1994 20:54:33 -0500 Received: from dross.auspost.com.au ([192.245.13.1]) by yarrina.connect.com.au with SMTP id AA24487 (5.67b8/IDA-1.5 for ); Wed, 9 Mar 1994 11:53:57 +1000 Received: by dross.auspost.com.au id AA10214 (5.65c/IDA-1.4.4); Wed, 9 Mar 1994 11:52:29 +1100 Date: Wed, 9 Mar 1994 11:52:29 +1100 From: Dave Cole Message-Id: <199403090052.AA10214@dross.auspost.com.au> To: hille@rz.informatik.uni-hamburg.d400.de Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <281*/S=hille/OU=rz/OU=informatik/PRMD=uni-hamburg/ADMD=d400/C=de/@MHS> (message from Gunter on Tue, 8 Mar 1994 06:25:20 -0500) Subject: Re: WSAASyncSelect() reenabling Hmm.. I can remember some of this confusing me for a while. It is quite a long time since I wrote this stuff. The program I wrote connected to a unix based server and allowed DDE connections to request data from the unix server. The server was written to allow live stock market data to be fed into Excel spreadsheets. Last I heard, the program was working in a stable fashion. I developed it using the TCP/IP that you can get for MS Windows for Workgroups. The client was using Sun PC/NFS (this caused no end of problems in the first release of their WINSOCK stuff, previously I had been trying to use their MS-DOS socket library in Windows [arrrg!!]). I did some further testing with the freely available Trumpet stuff which in my experience was by far the best of the batch. So you could say that my code worked with multiple implementations of WINSOCK. The program uses asynchronous socket I/O exclusively. Here are some of the bits o' code from the program. If anyone sees something that I am doing wrong, please tell me, I worked out all I know from the WinSock Guide To Programming (or whatever). - Dave ------------------------------ cut here ------------------------------ #define SOCKLIB_VERSION 0x0101 #define WM_SOCK_START (WM_USER + 25) /* start the ball rolling */ #define WM_SOCK_EVENT (WM_USER + 26) /* socket event */ #define WM_SOCK_GETHOSTBYNAME (WM_USER + 27) /* gethostbyname complete */ #define WM_SOCK_GETSERVBYNAME (WM_USER + 28) /* getservbyname complete */ static char szQuotesHost[] = "quoteshost"; static char szQuotesService[] = "newquotes"; static char szSocketWinClass[] = "BBYLive_socket"; static char hostbuff[MAXGETHOSTSTRUCT]; /* data from host buffer */ static struct WSAData WSAData; /* SocketLib data buffer */ static HWND sockWnd; /* Socket window */ static SOCKET sock = INVALID_SOCKET; /* The socket associated with the class */ static struct sockaddr_in addr; /* Build address for socket to connect to */ static BOOL connected = FALSE; /* Are we connected to server? */ static WORD requestIdx; /* Current write position in request at head of queue */ static WORD quoteIdx; /* Current read position in quote coming from server */ static struct Quote quote; /* Quote currently being read from server */ static long unix_delall; /* Byte-swapped REQ_DELALL */ /* Handle a queue of instrument requests to the server */ struct InstRequest { struct Request req; /* The instrument request */ struct InstRequest far *next; /* Next request in the queue */ }; static struct InstRequest far *requestQueue; /* Close the socket to the unix server. This is used in the event or * errors, the program may later try to re-open the connection to the * server and restore context. */ static void do_close() { WORD ret; connected = FALSE; if (sock != INVALID_SOCKET) { ret = closesocket(sock); if (ret == SOCKET_ERROR) socket_error("closesocket()", WSAGetLastError()); sock = INVALID_SOCKET; } } /* Shutdown the socket to the server and clean up the WINSOCK library */ static void close_socket() { log_msg(LOG_NETWORK, "finish"); do_close(); if (WSAIsBlocking()) if (WSACancelBlockingCall()) socket_error("WSACancelBlockingCall()", WSAGetLastError()); if (WSACleanup()) socket_error("WSACleanup()", WSAGetLastError()); } /* Read some data from the server socket. When a complete instrument * has been read, update all DDE conversations that are interested. */ static void socket_read_ready() { int nread; /* Number of bytes read this time around */ int error; /* Error returned from socket read */ for (;;) { error = 0; /* Try to read as much as possible from the quotes * server (up to a complete instrument) */ nread = recv(sock, ((char *)"e) + quoteIdx, sizeof(quote) - quoteIdx, 0); if (nread == 0) /* No more data ready */ break; if (nread == SOCKET_ERROR) { error = WSAGetLastError(); if (error == EWOULDBLOCK) /* No more data ready */ break; /* Error: close socket and retry */ socket_error("recv()", error); do_close(); queue_all_inst(); break; } else { /* Got some more data from quotes server */ quoteIdx += nread; if (quoteIdx == sizeof(quote)) { /* Have a complete instrument. * Update it. When done, prepare to read the next * instrument */ log_msg(LOG_SERVER, "read: %s", quote.q_code); unix_update("e); quoteIdx = 0; } } } } /* Write requests to the quotes server */ static void socket_write_ready() { int nwrite; int error; struct InstRequest far *tmp; while (requestQueue) { /* Get the request at the head of the queue and send as * much as possible to the quotes server. */ nwrite = send(sock, (char far *)&requestQueue->req + requestIdx, sizeof(requestQueue->req) - requestIdx, 0); if (nwrite != SOCKET_ERROR) { /* Managed to send data to the server */ requestIdx += nwrite; if (requestIdx == sizeof(requestQueue->req)) { /* Completed the request - remove it from the queue * and delete it. * Oops - first check to see if this was a shutdown request. * Prepare to send the next request */ if (!requestQueue->req.r_code[0] && requestQueue->req.r_request == unix_delall) { close_socket(); PostQuitMessage(0); return; } tmp = requestQueue; requestQueue = requestQueue->next; _ffree(tmp); requestIdx = 0; } } else { /* Some sort of error sending to server. */ error = WSAGetLastError(); if (error == EWOULDBLOCK) /* No problems, server can not accept any more * data just now */ return; else { /* Error: close socket and retry */ socket_error("send()", error); do_close(); queue_all_inst(); return; } } } } /* Hooray, we have connected to the quotes server. */ static void socket_connected() { set_status("Connected to quotes server"); log_msg(LOG_NETWORK, "connected to quotes server"); connected = TRUE; } /* Perform a select the quotes server socket. When an event occurs * the WINSOCK library will sent a WM_SOCK_EVENT message to the socket * window message proc. */ static int do_select() { LONG events; if (connected) events = 0; else events = FD_CONNECT; if (WSAAsyncSelect(sock, sockWnd, WM_SOCK_EVENT, events|FD_CLOSE|FD_READ|FD_WRITE) != SOCKET_ERROR) return OK; return socket_error("WSAAsyncSelect()", WSAGetLastError()); } /* This next define was to try a different technique for doing * asynchronous connects under MS TCP/IP. If you exit the program * before the connect completes (remote machine not turned on or * whatever), then when the connection times out we are dropped back * to the DOS prompt. Interestingly, none of the other TCP/IP I tried * do this. */ /* #define USE_IOCTL */ /* Create the socket to use for talking to the server */ static int do_newsocket() { int error; #ifdef USE_IOCTL int ret; DWORD mode; #endif if ((sock = socket(PF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET) return socket_error("socket()", WSAGetLastError()); #ifdef USE_IOCTL mode = 1; if (ioctlsocket(sock, FIONBIO, &mode) == SOCKET_ERROR) { ret = socket_error("ioctlsocket()", WSAGetLastError()); do_close(); return ret; } #else do_select(); #endif set_status("Connecting to %d.%d.%d.%d/%d", addr.sin_addr.s_net, addr.sin_addr.s_host, addr.sin_addr.s_lh, addr.sin_addr.s_impno, htons(addr.sin_port)); log_msg(LOG_NETWORK, "connect to: %d.%d.%d.%d/%d", addr.sin_addr.s_net, addr.sin_addr.s_host, addr.sin_addr.s_lh, addr.sin_addr.s_impno, htons(addr.sin_port)); if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) == SOCKET_ERROR && (error = WSAGetLastError()) != WSAEWOULDBLOCK) return socket_error("connect()", error); return do_select(); } /* The WSAAsyncGetServByName has completed, save the data */ static void save_service() { struct servent Servent; /* Service to connect */ _fmemcpy((void*)&Servent, hostbuff, sizeof(Servent)); addr.sin_port = Servent.s_port; } /* Issue a WSAAsyncGetServByName to find the quotes service */ static int do_getservbyname() { set_status("Get service by name (%s)", szQuotesService); log_msg(LOG_NETWORK, "get service: %s", szQuotesService); if (WSAAsyncGetServByName(sockWnd, WM_SOCK_GETSERVBYNAME, szQuotesService, "tcp", hostbuff, MAXGETHOSTSTRUCT)) return OK; return socket_error("WSAAsyncGetServByName()", WSAGetLastError()); } /* The WSAAsyncGetHostByName has completed, save the data */ static void save_hostname() { struct hostent Hostent; /* Address of host to connect */ _fmemcpy((void*)&Hostent, hostbuff, sizeof(Hostent)); _fmemcpy((char FAR *)&addr.sin_addr, (char FAR *)&Hostent.h_addr[0], Hostent.h_length); } /* Issue a WSAAsyncGetHostByName to find our quotes server */ static int do_gethostbyname() { set_status("Get host by name (%s)", szQuotesHost); log_msg(LOG_NETWORK, "get host: %s", szQuotesHost); if (WSAAsyncGetHostByName(sockWnd, WM_SOCK_GETHOSTBYNAME, szQuotesHost, hostbuff, MAXGETHOSTSTRUCT)) return OK; return socket_error("WSAAsyncGetGetHostByName()", WSAGetLastError()); } /* All socket events come to this window proc. */ long EXPORT socket_wnd_proc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { WORD event; WORD error; event = WSAGETSELECTEVENT(lParam); error = WSAGETASYNCERROR(lParam); switch (message) { case WM_SOCK_START: /* We start the ball rolling by building the * quotes server IP address. Get the address of the * quotes host.first. * When the gethostbyname operation finishes, windows sends the * WM_SOCK_GETHOSTBYNAME message back here. */ do_gethostbyname(); break; case WM_SOCK_GETHOSTBYNAME: /* Have just got the host address. Save the data and then * request the service port. * When the getservbyname operation finishes, windows sends the * WM_SOCK_GETSERVBYNAME message back here. */ if (error) { /* gethostbyname failed for some reason */ if (socket_error("WSAAsyncGetHostByName", error) == RETRY) do_gethostbyname(); break; } save_hostname(); do_getservbyname(); break; case WM_SOCK_GETSERVBYNAME: /* Have just got the service port. Save the data and then * request the service port. * When the getservbyname operation finishes, windows sends the * WM_SOCK_GETSERVBYNAME message back here. */ if (error) { if (socket_error("WSAAsyncGetServByName", error) == RETRY) do_getservbyname(); break; } save_service(); do_newsocket(); break; case WM_SOCK_EVENT: switch (event) { case FD_CLOSE: /* Say what??? Socket has been closed at the other end. * Re-establish the connection and queue all of the * instruments with the quotes server. */ sock = INVALID_SOCKET; connected = FALSE; log_msg(LOG_NETWORK, "quotes server terminated"); do_newsocket(); queue_all_inst(); break; case FD_CONNECT: if (error) { do_close(); socket_error("connect", error); break; } socket_connected(); do_select(); break; case FD_READ: socket_read_ready(); break; case FD_WRITE: socket_write_ready(); break; } break; default: /* Passes it on if unproccessed */ return DefWindowProc(hwnd, message, wParam, lParam); } return 0; } /* Queue a request to the quotes server. * If there is already one in the queue, ignore this request. * If this is the only request, and the socket is ready for writing * then try to write the request */ void request_quote(struct Quote far *pQuote, LONG request) { struct InstRequest far *pRequest, far *tmp; for (tmp = requestQueue; tmp; tmp = tmp->next) if (!_fstrcmp(tmp->req.r_code, pQuote->q_code)) return; pRequest = _fmalloc(sizeof(*pRequest)); _fmemset(pRequest, 0, sizeof(*pRequest)); _fstrncpy(pRequest->req.r_code, pQuote->q_code, sizeof(pRequest->req.r_code)); switch (request) { case REQ_ADD: log_msg(LOG_SERVER, "request add: %Fs", pQuote->q_code); break; case REQ_DELETE: log_msg(LOG_SERVER, "request delete: %Fs", pQuote->q_code); break; case REQ_DELALL: log_msg(LOG_SERVER, "request delete all"); break; } swap2((BYTE*)&request, ((BYTE*)&request) + 3); swap2(((BYTE*)&request) + 1, ((BYTE *)&request) + 2); pRequest->req.r_request = request; if (requestQueue) { for (tmp = requestQueue; tmp->next; tmp = tmp->next) ; tmp->next = pRequest; } else requestQueue = pRequest; if (connected) socket_write_ready(); } /* External code shuts down the connection to the server by calling this */ void finish_quotes() { struct Quote quote; if (connected) { /* If we are online the server needs us to send a Delete All * request. The request sending code will detect when the * request has been sent and will terminate. */ quote.q_code[0] = '\0'; request_quote("e, REQ_DELALL); } else { /* Not yet connected, do not need to tell server anything */ close_socket(); PostQuitMessage(0); } } /* Register the window class that will receive the socket messages */ static BOOL init_socket_class(HANDLE hInstance) { WNDCLASS wc; wc.style = 0; wc.lpfnWndProc = socket_wnd_proc; wc.cbClsExtra = wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = NULL; wc.hCursor = wc.hbrBackground = 0; wc.lpszMenuName = NULL; wc.lpszClassName = szSocketWinClass; return RegisterClass(&wc); } /* Initialise the socket library * Once set up, this module should run almost by itself. */ BOOL init_socket(HANDLE hInstance) { int ret; if (!init_socket_class(hInstance)) return FALSE; if (ret = WSAStartup(SOCKLIB_VERSION, &WSAData)) { socket_error("WSAStartup()", ret); return FALSE; } sockWnd = CreateWindow(szSocketWinClass, "", 0, 0, 0, 0, 0, NULL, NULL, hInstance, NULL); if (!sockWnd) { if (WSACleanup()) socket_error("WSACleanup()", WSAGetLastError()); return FALSE; } PostMessage(sockWnd, WM_SOCK_START, 0, 0); addr.sin_family = PF_INET; unix_delall = REQ_DELALL; /* Should use htonl() I suppose */ swap2((BYTE*)&unix_delall, ((BYTE*)&unix_delall) + 3); swap2(((BYTE*)&unix_delall) + 1, ((BYTE *)&unix_delall) + 2); return TRUE; } From paul@atlas.dev.abccomp.oz.au Wed Mar 9 09:17:37 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00851; Tue, 8 Mar 1994 23:05:03 -0500 Received: by usage.csd.unsw.OZ.AU id AA23744 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 9 Mar 1994 14:05:11 +1000 Received: by atlas (4.1/1.35) id AA11831; Wed, 9 Mar 94 14:17:38 EST Message-Id: <9403090417.AA11831@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 9 Mar 1994 14:17:37 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: ZANNA%LABEN@icil64.cilea.it, Multiple recipients of list Subject: Re: Trumpet WSK recvfrom() Thus expounded "A.ZANNA" on Mar 4, 3:12am: /-------------------- |Hallo to everyone on the list. | |All samples ported and worked fine, EXCEPT for the one that calls recvfrom(). |I get instant GPF when I call this. I'm pretty confident the code is OK |(worked on UNIX, works when I use recv rather than recvfrom(), structs are OK...) | Try to make sure that all the pointers you apss are valid, using the Win31 functions IsValidReadPtr() and IsValidWritePtr(). Note that the from/fromlen parameters are optional, and may be NULL, but this was left out of all but the last spec., so maybe they are required to be valid and non-NULL for Trumpet. -- 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 Mar 9 09:27:07 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01897; Tue, 8 Mar 1994 23:15:17 -0500 Received: by usage.csd.unsw.OZ.AU id AA24041 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 9 Mar 1994 14:14:43 +1000 Received: by atlas (4.1/1.35) id AA11863; Wed, 9 Mar 94 14:27:07 EST Message-Id: <9403090427.AA11863@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 9 Mar 1994 14:27:07 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: natale@acec.com, Multiple recipients of list Subject: Re: WSAASyncSelect() reenabling Thus expounded Bob Natale on Mar 8,11:39am: /-------------------- | |Well, this is still fresh in my mind from p. 91 of the spec (as I |am addressing a similar problem on another thread). In the case you |descirbe, assuming you have posted a WSAAsyncSelect() for FD_WRITE, |and you receive an FD_WRITE, and you start to send, and you then |(eventually) receive a WSAEWOULDBLOCK, then you should receive another |FD_WRITE (without needing another WSAAsyncSelect() for it) _when_ |"buffer space becomes available". | |I think that is very clear from the paragraph on FD_WRITE behavior |on p. 91. So it sounds to me, based just on your description above, |that the NetManage implementation is behaving correctly and Trumpet |is not. | |I'd like to know if others interpret this differently. Nope - that sounds exactly as it is supposed to work. You should only have call WSAAsyncSelect() once for a socket (unless you want to change the messages you are interested in, of course!). Then, if while writing you get a WSAEWOULDBLOCK, then you wait for an FD_WRITE message to be posted to you to tell you its safe to write again, then keep writing until you get WSAEWOULDBLOCK. Remember also, you will only get one FD_WRITE, and you can assume its safe to write as many times as you like until you get WSAEWOULDBLOCK back. Its not like FD_READ, where you get one everytime there's data available. -- 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 Mar 9 09:30:52 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA02227; Tue, 8 Mar 1994 23:18:46 -0500 Received: by usage.csd.unsw.OZ.AU id AA24145 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 9 Mar 1994 14:18:27 +1000 Received: by atlas (4.1/1.35) id AA11874; Wed, 9 Mar 94 14:30:53 EST Message-Id: <9403090430.AA11874@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 9 Mar 1994 14:30:52 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: richard@locomotive.com, Multiple recipients of list Subject: Re: Does "initially" mean anything? Thus expounded Richard Clayton on Mar 8,11:58am: /-------------------- |In message natale@acec.com writes: | |> "If an event is true when the application initially |> calls WSAAsyncSelect() or when the reenabling function |> is called, then a message is posted as appropriate." |> |> My main question is: Is the word "initially" there on purpose? |> If so, does it imply that a subsequent call to WSAAsyncSelect |> does not or might not trigger the same behavior? Or is "initially" |> in there just to emphasize that if a certain state arises before |> the app has a chance to WSAAsyncSelect(), it will nonetheless |> be notified? | | |If instead you arm FD_READ|FD_WRITE initially then you will |be continually handling totally useless FD_WRITE events (useless |because you have nothing further to send most of the time). No - this is incorrect. You will ONLY get an FD_WRITE message if one of your send()s returned WSAEWOULDBLOCK. You will not get another one until another send() has failed with WSAEWOULDBLOCK. Since with telnet its very unlikely you'll fill the transmit buffer, you can safely enable FD_READ|FD_WRITE at the beginning, and you may never actually get an FD_WRITE message. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From ZANNA%LABEN@icil64.cilea.it Wed Mar 9 06:59:28 1994 Received: from icil64.cilea.it by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10952; Wed, 9 Mar 1994 06:59:28 -0500 Received: from DECNET-MAIL (ZANNA@LABEN) by ICIL64.CILEA.IT (PMDF V4.2-14 #2920) id <01H9RKIMBDAO99E2MJ@ICIL64.CILEA.IT>; Wed, 9 Mar 1994 11:03:01 MET-DST Date: Wed, 9 Mar 1994 11:03:00 MET-DST From: "A.ZANNA" Subject: recvfrom() problems solved! To: winsock-hackers@sunsite.unc.edu Message-Id: <01H9RKIMCFVM99E2MJ@ICIL64.CILEA.IT> X-Vms-To: ICIL64::IN%"winsock-hackers@sunsite.unc.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Hallo, everybody. A few days ago I posted a message stating I couldn't get recvfrom() to work properly (trumpet winsock 1.0 + BC++ + EasyWin). 'twas all my fault, of course. Hope that the following helps some other newbie... Meanwhile, tnx to all those who mailed me some suggestions. - It is possible and legitimate to write any kind of windows application using BC EasyWin. This includes calling DDLs and, of course, Winsock. The Borland docs even suggest plugging an InitEasyWin() (sp?) in normal WinMain-style programs, in order to get a handy debugging console. --> It is possible, with some care, to write unix-style socket+stdio applications with BC/EasyWin. This is NOT what you should do, but it's very useful to get you started. The Trumpet demo clients look like they're written under BC/EasyWin. - (This is what caught me) IF YOU DO ANY BLOCKING CALLS (such as a recv() or a recvfrom() on a blocking socket) SET THE DATA SEGMENT TO FIXED IN THE MODULE DEFINITION FILE. By default, BC uses a MOVEABLE DISCARDABLE segment. The "Blocking, Non Blocking & Data Volatility" page on the Winsock has a small warning to this effect. Perhaps a little suggestion like this could be added. So, what caused the crashes was probably the data buffers being zapped around from under recvfrom(). It is VERY funny that my other tests, using recv() appeared to work reliably. I did, on occasion, get a random crash when the program exited, but I couldn't possibly relate the two things. thanks from a happier hacker Andy -------- Andy Zanna SW R&D, LABEN ZANNA%LABEN@icil64.cilea.it From richard@locomotive.com Wed Mar 9 09:56:35 1994 Received: from locosoft.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA06427; Wed, 9 Mar 1994 11:58:48 -0500 Date: Wed, 09 Mar 94 09:56:35 GMT From: richard@locomotive.com (Richard Clayton) Reply-To: richard@locomotive.com Message-Id: <2259@locomotive.com> To: rcq@ftp.com Cc: winsock-hackers@sunsite.unc.edu Subject: Re: Does "initially" mean anything? X-Mailer: PCElm 1.09 Lines: 13 My thanks to Paul Brooks & Bob Quinn for making me read further down page 91 and thus simplifying my code for FD_WRITE. My apologies for the confusion I may have caused. I look forward to similar clarification about 2/4 byte BOOLs for my ioctlsocket question :) richard ------------------------------------------------------------------------- Richard Clayton, Locomotive Software tel: +44 306 740606 Dorking Business Park, DORKING, Surrey, UK. RH4 1YL fax: +44 306 885529 "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM From hille@rz.informatik.uni-hamburg.d400.de Thu Mar 10 14:06:51 1994 Received: from ixgate02.dfnrelay.d400.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18241; Thu, 10 Mar 1994 07:09:00 -0500 X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Thu, 10 Mar 1994 13:08:36 +0100 X400-Received: by /PRMD=uni-hamburg/ADMD=d400/C=de/; Relayed; Thu, 10 Mar 1994 13:06:51 +0100 Date: Thu, 10 Mar 1994 13:06:51 +0100 X400-Originator: hille@rz.informatik.uni-hamburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uni-hamburg/ADMD=d400/C=de/;940310130651] X400-Content-Type: P2-1984 (2) Content-Identifier: 289 Alternate-Recipient: Allowed From: Gunter Message-Id: <289*/S=hille/OU=rz/OU=informatik/PRMD=uni-hamburg/ADMD=d400/C=de/@MHS> To: winsock-hackers@sunsite.unc.edu (Non Receipt Notification Requested) Subject: Re: Trumpet WSK recfrom() The recfrom works with Trumpet 1.0a(4) without problems in my application. Here is the piece of code: procedure TMyWindow.RcvDgram; var Pbuf : array[0..255] of char; len : integer; nbytes : integer; DragDC : HDC; SPort : u_short; APort : array[0..5] of char; begin len := 16; nbytes := recvfrom(session, Pbuf, SizeOf(PBuf), 0, @Netaddr, @len); if nbytes > 0 then begin PBuf[nbytes] := #0; {make it null terminated} SPort := ntohs(Netaddr.sin_port); Str(SPort,APort); StrCat(PBuf,' -> port: '); StrCat(PBuf,APort);StrCat(PBuf,', from: '); StrCat(PBuf,inet_ntoa(Netaddr.sin_addr.s_addr)); DragDC := GetDC(HWindow); WriteLog(PBuf); TextOut(DragDC,1,row,PBuf,StrLen(PBuf));row := row + 20; ReleaseDC(HWindow,DragDC); end; end; Gunter From natale@acec.com Thu Mar 10 05:41:57 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10341; Thu, 10 Mar 1994 10:58:35 -0500 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06852 for marke@firefox.co.uk; Thu, 10 Mar 94 10:43:56 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA12992; Thu, 10 Mar 1994 10:42:34 -0500 Date: Thu, 10 Mar 1994 10:41:57 EST From: Bob Natale Subject: Re: Re: WSAAsyncSelect() reenab To: marke@firefox.co.uk Cc: Multiple recipients of list Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/Plain; CHARSET=US-ASCII > From: Mark Edwards > Date: Thu, 10 Mar 1994 06:26:35 -0500 Hi Mark, > My understanding is that once a WSAAsyncSelect() with sets the FD_WRITE > then until another WSAAsyncSelect() alters the behaviour, the send() > should work as follows. > > The send() function takes user data and buffers/writes the data to the > TCP/IP stack. If there is any send data buffer space still available > after the current user buffer is processed then you will receive an > FD_WRITE. This appears to be incorrect as stated. The act of sending data successfully does not result in another FD_WRITE being fired off by the DLL. > If on the other hand you get a WSAEWOULDBLOCK from the send(), then the > moment that the stack frees up any buffer space (albeit only 1 byte) the > code should give you an FD_WRITE. This is correct. > I think that concurs with Bob's interpretation. As amended above (assuming you're referring to _this_ Bob's interpretation! :-) > I would consider any stack deviating from that to be 'suspect'. > The objective in using WSAAsyncSelect() is that it need only be > called once (or each time the socket profile needs changing) and > thereafter the DLL does all the work for you by posting messages > at the appropriate time. It cuts out all that tedious looping > required to call select(). Yes...this is absolutely true. I am constantly (...repeatedly, actually) amazed at how many programmers I encounter who have a mental block in this regard. Every new programmer we have put on a WinSock app (except for one person over the past two years) has started off employing a multiple WSAAsyncSelect() strategy where a single one at the outset would have sufficed. They usually reach this stage after we ween them from the "blocking mode" stage! :-) A lot of these folks--who are typically very sharp overall--are wanna-bees in the "Windows is brain-dead; UNIX is elegant" camp...is there more than just a correlation at work here? (BTW, the most distinguishing characteristic of the one person who did not fall prey to these fallacies is that he had a highly pragmatic (non-CS) training in the business world before deciding to delve into software development for a living.) Go figger, BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com From rcq@mailserv-D.ftp.com Thu Mar 10 05:44:10 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11515; Thu, 10 Mar 1994 11:03:28 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Mar 1994 10:44:44 -0500 Received: from rcq.aeolus.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA25964; Thu, 10 Mar 94 10:44:10 EST Date: Thu, 10 Mar 94 10:44:10 EST Message-Id: <9403101544.AA25964@mailserv-D.ftp.com> To: stcheng@eemips.tamu.edu Subject: Re: multicast IP 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 10 10:43:55 1994] Originating-Client: aeolus.ftp.com Content-Length: 777 > I've heard PC/TCP V2.3 supports multicast IP. > Does anyone out there know if the incoming Winsock v2.0 spec > will support multicast IP ? Our support of multicast is implicit, and fits nicely within the existing 1.1 specification. To send multicast, you get a UDP socket and either connect() or sendto() a multicast address. To receive multicast, you bind() to a multicast address. Simple. It would sure be nice if the v2.0 specification prescribed the use of multicast. It could certainly defer to the more complicated BSD approach (which I can't recite here off-hand), but as we've demonstrated it doesn't have to. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Thu Mar 10 05:44:07 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11525; Thu, 10 Mar 1994 11:03:30 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 10 Mar 1994 10:44:40 -0500 Received: from rcq.aeolus.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA25959; Thu, 10 Mar 94 10:44:07 EST Date: Thu, 10 Mar 94 10:44:07 EST Message-Id: <9403101544.AA25959@mailserv-D.ftp.com> To: marke@firefox.co.uk Subject: Re: Re: WSAAsyncSelect() reenab 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 10 10:43:54 1994] Originating-Client: aeolus.ftp.com Content-Length: 2540 > My understanding is that once a WSAAsyncSelect() with sets the FD_WRITE > then until another WSAAsyncSelect() alters the behaviour, the send() > should work as follows. I'm not sure what you mean altering the behaviour. The spec states that "issuing a WSAAsyncSelect() for a socket cancels any previous WSAAsyncSelect() for the same socket". But it also cautions that "the application must be prepared to receive network event messages after cancellation," which relates to the fact you may have messages already waiting in your queue when you call WSAAsynchSelect(). And you must also consider what behaviour WSAAsynchSelect() causes "initially" after it's called (e.g. if there's data pending to be read, you will get an FD_READ notification even if there'd been a message sent before, and a "reenabling function" hadn't been called). > The send() function takes user data and buffers/writes the data to the > TCP/IP stack. If there is any send data buffer space still available > after the current user buffer is processed then you will receive an > FD_WRITE. Wrong. The 1.1 spec clearly states when a WinSock DLL should post FD_WRITE messages: "when a socket is first connected with connect() or accepted with accept(), and then after a send() or sendto() fails with WSAEWOULDBLOCK and buffer space becomes available." In other words, a WinSock implementation should NOT post an FD_WRITE after a send() or sendto() succeeds. > If on the other hand you get a WSAEWOULDBLOCK from the send(), then the > moment that the stack frees up any buffer space (albeit only 1 byte) the > code should give you an FD_WRITE. This is true. However, notification after freeing of one-byte is unlikely since it would probably be a symptom of a TCP/IP stack afflicted with the Silly-Window syndrome. > I think that concurs with Bob's interpretation. Half of it does, anyway :) > I would consider any stack > deviating from that to be 'suspect'. The objective in using WSAAsyncSelect() > is that it need only be called once (or each time the socket profile needs > changing) and thereafter the DLL does all the work for you by posting > messages at the appropriate time. It cuts out all that tedious looping > required to call select(). Yes!! An application that uses asynchronous notification properly, has simplified code and lower processor overhead to show for it. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From marke@firefox.co.uk Thu Mar 10 17:42:20 1994 Received: from relay2.pipex.net by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00851; Thu, 10 Mar 1994 12:54:25 -0500 Received: from FFSCO.firefox.co.uk by relay2.pipex.net with SMTP (PP) id <18077-0@relay2.pipex.net>; Thu, 10 Mar 1994 17:54:06 +0000 From: Mark Edwards X-Mailer: SCO System V Mail (version 3.2) To: winsock-hackers@sunsite.unc.edu Subject: Re: Re: WSAAsyncSelect() reenab Date: Thu, 10 Mar 94 17:42:20 gmt Message-Id: <9403101742.aa03082@ffsco.firefox.co.uk> BobN, BobQ, The perils of writing winsock email off the top of your head. You both picked up the point I did when I checked back to the spec after I'd written the email. Yes the FD_WRITE does only appear after a successful connection establishment (connect()/accept()) or after send() sendto() have returned WSAEWOULDBLOCK. It's only Wednesday, god knows what state my brain will be in by Friday. I think I'll just go stick my head in a bucket. Mark. - ---------------------------------------------------------- Mark S. Edwards Firefox Communications Ltd, Cranmore House, Cranmore Boulevard, Solihull, West Midlands. United Kingdom. B90 4RX. phone : 021 609 6090 (intl, 44 21 609 6090) Fax : 021 609 6060 (intl, 44 21 609 6060) Internet: marke@firefox.co.uk - ---------------------------------------------------------- From hall@cs.sfu.ca Thu Mar 10 06:18:28 1994 Received: from cs.sfu.ca by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA14515; Thu, 10 Mar 1994 17:19:07 -0500 Received: from monoceros.cs.sfu.ca by cs.sfu.ca with SMTP id AA09339 (5.65c/IDA-1.4.4 for ); Thu, 10 Mar 1994 14:18:34 -0800 Received: by monoceros.cs.sfu.ca id AA21817 (5.65c/IDA-1.4.4 for winsock-hackers@SunSITE.Unc.EDU); Thu, 10 Mar 1994 14:18:28 -0800 Date: Thu, 10 Mar 1994 14:18:28 -0800 From: Gary Hall Message-Id: <199403102218.AA21817@monoceros.cs.sfu.ca> To: winsock-hackers@SunSITE.Unc.EDU Subject: What does WSANO_DATA mean I have a call to gethostbyaddr that is failing with the WSANO_DATA error. The error description is: "Valid name, no data record of requested type". I am at a loss to know what this means. Can anyone enlighten me? Gary Hall | Voice (604) 291-3208 | INTERNET: hall@cs.sfu.ca Centre for Systems Science | Fax (604) 291-4424 | Simon Fraser University | Burnaby, B.C. V5A 1S6 | From paul@atlas.dev.abccomp.oz.au Fri Mar 11 06:30:19 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA09666; Thu, 10 Mar 1994 20:18:54 -0500 Received: by usage.csd.unsw.OZ.AU id AA23248 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Fri, 11 Mar 1994 11:17:59 +1000 Received: by atlas (4.1/1.35) id AA20555; Fri, 11 Mar 94 11:30:21 EST Message-Id: <9403110130.AA20555@atlas> From: paul@atlas.abccomp.oz.au Date: Fri, 11 Mar 1994 11:30:19 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: richard@locomotive.com, Multiple recipients of list Subject: BOOLs in ioctlsocket() Thus expounded Richard Clayton on Mar 10, 7:26am: /-------------------- | |I look forward to similar clarification about 2/4 byte BOOLs |for my ioctlsocket question :) OK, Richard, I'll byte (pun intended). Answer: The 1.1 spec. at the bottom of page 35 quite clearly says "_argp_ points at a _BOOL_ in which ioctlsocket() stores the result." The WINDOWS.H file I have has typedef int BOOL; And the Windows Help for the Borland Compiler states: BOOL: a 16-bit Boolean value. This makes it clear to me that the WINDSOCK.DLL should only set a 16-bit value for ioctlsock(SIOCATMARK,..), not a 32-bit value. unless you are running a 32-bit Windows and DLL. Discussion: The size of an integer will be different depending on environment, - for 32-bit versions of windows, an 'int', and by extension a BOOL, will be 32-bits long. This is the whole problem with using 'int' for anything designed to be portable. MS _should_ have #defined BOOL from 'short', not 'int', to avoid just these problems. (IN fact, in DOS code I normally typedef a BOOL as 'unsigned char', but anyway). The ioctlsocket() definition has the argument as a pointer to an 'unsigned long', and ioctlsocket(FIONBIO,...) uses a boolean value as the input, but this is explicitly stated to be a real 'unsigned long'. I beleive these inconsistencies are a recipe for disaster, and the ioctlsocket() return SHOULD have been consistent with the argument, and the value should have been put into an 'unsigned long', NOT a BOOL. Any Winsock implementation that sets a 32-bit region after a call ti ioctlsocket(SIOCATMARK,...) has a bug, and this should be reported to the developer ASAP. Don't be too hard on them, as the last sentence on page 35 is easy to miss, and all other things on the page indicate a 32-bit longword is the correct argument. Flag it for discussion for Winsock v2. As always, these are my own thoughts only. -- 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 munster@mcs.com Thu Mar 10 11:32:24 1994 Received: from Mercury.mcs.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11121; Thu, 10 Mar 1994 20:34:53 -0500 Received: by mercury.mcs.com (/\==/\ Smail3.1.28.1 #28.1) id ; Thu, 10 Mar 94 19:35 CST Date: Thu, 10 Mar 94 19:32:24 PST From: munster@mcs.com Subject: RE: multicast IP To: winsock-hackers@sunsite.unc.edu X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >Fellow hackers, > >I've heard PC/TCP V2.3 supports multicast IP. >Does anyone out there know if the incoming Winsock v2.0 spec >will support multicast IP ? I have the NEWT SDK and you can Multicast with that. Let me check to see if the calls are "winsockable"... -- Jerry ******************************************************** * Jerry Ablan DOS & Windows Programming * * Criminal Software Networking Consultant * * "It's too good to be bad!" munster@mcs.com * ******************************************************** * GAT: d--(?) -p+ c++++ l++ u+ c+(*) m+(++) s++/++ !n * * h---(--) f+ g+++ w++ t++ r++ y**(--) * ******************************************************** * Futue te ipsum et caballum tuum! * ******************************************************** From alun@internet.wst.com Fri Mar 11 13:56:03 1994 Received: from internet.wst.com ([198.64.82.8]) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA27860; Fri, 11 Mar 1994 20:53:43 -0500 Received: by internet.wst.com (4.1/SMI-4.1) id AA17851; Fri, 11 Mar 94 19:56:04 CST From: alun@internet.wst.com (Alun Jones) Message-Id: <9403120156.AA17851@internet.wst.com> Subject: Re: Does "initially" mean anything? To: rcq@ftp.com, winsock-hackers@sunsite.unc.edu Date: Fri, 11 Mar 94 19:56:03 CST In-Reply-To: <9403082103.AA08580@mailserv-D.ftp.com>; from "Bob Quinn" at Mar 10, 94 6:39 am X-Mailer: ELM [version 2.3 PL11] From johnt@unipalm.co.uk Sat Mar 12 15:20:48 1994 Received: from unipalm.co.uk (unipalm.unipalm.co.uk) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA27565; Sat, 12 Mar 1994 10:13:54 -0500 Received: from brimstone.unipalm.co.uk by unipalm.co.uk (4.1/SMI-4.1 (unipalm 1.17)) id AA13957; Sat, 12 Mar 94 15:13:49 GMT Received: from dreft.unipalm.co.uk by brimstone.unipalm.co.uk (4.1/SMI-4.1 brimstone 1.19) id AA00521; Sat, 12 Mar 94 15:13:46 GMT Message-Id: <9403121513.AA00521@brimstone.unipalm.co.uk> Priority: Normal To: winsock-hackers@sunsite.unc.edu Reply-To: johnt@unipalm.co.uk Mime-Version: 1.0 From: John Taylor Subject: Re: WSAAsyncSelect() reenab Date: Sat, 12 Mar 94 15:20:48 GMT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"; X-MAPIrenderingpos=0xFFFFFFFF Content-Transfer-Encoding: 7bit On Sat, 12 Mar 94 07:47:20 GMT Bob Natale Wrote: > Yes...this is absolutely true. I am constantly (...repeatedly, > actually) amazed at how many programmers I encounter who have > a mental block in this regard. Every new programmer we have put > on a WinSock app (except for one person over the past two years) > has started off employing a multiple WSAAsyncSelect() strategy > where a single one at the outset would have sufficed. They > usually reach this stage after we ween them from the "blocking > mode" stage! :-) A lot of these folks--who are typically very > sharp overall--are wanna-bees in the "Windows is brain-dead; > UNIX is elegant" camp...is there more than just a correlation at > work here? [After having battled with Windows for several years, and still thinking Unix is better in ALL respects(Smaller, quicker, more portable, easier to program ...). I couldn't resist replying to this :-) ] After having admitted that most trained programmers find using Windows not intuitive. (The only person who could understand the interface hadn't been trained in good programming techniques) Why do you find it surprising that so many people conclude that "Windows is brain-dead". If 100 trained engineers said, they could understand why a bridge doesn't collapse, and an untrained salesman said it looked fine. Would you think that there was something wrong with the bridge, or the salesman new better than the trained engineers ? My bet goes with the Engineers :-) JohnT From rcq@mailserv-D.ftp.com Sat Mar 12 12:28:28 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19930; Sat, 12 Mar 1994 17:29:04 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 12 Mar 1994 17:29:01 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12319; Sat, 12 Mar 94 17:28:28 EST Date: Sat, 12 Mar 94 17:28:28 EST Message-Id: <9403122228.AA12319@mailserv-D.ftp.com> To: hall@cs.sfu.ca Subject: Re: What does WSANO_DATA mean 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 Mar 12 17:28:19 1994] Originating-Client: oysters.ftp.com Content-Length: 846 > I have a call to gethostbyaddr that is failing with the WSANO_DATA error. > The error description is: "Valid name, no data record of requested type". > I am at a loss to know what this means. Can anyone enlighten me? In Berkeley-ese it means "Valid name, no data reocrd of requested type." Translated to Windows Sockets-ese, after gethostbyname() fails this means "I'm sure this is a very nice hostname, but we can't find any record of it to give you an IP address back." Bottom line: that hostname (or IP address, for gethostbyaddr()) is not in your local hosttable (if you have one configured), and/or not known by your Domain Name Server (if you have one configured and responding). Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Sat Mar 12 12:28:27 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19945; Sat, 12 Mar 1994 17:29:08 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Sat, 12 Mar 1994 17:29:00 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA12316; Sat, 12 Mar 94 17:28:27 EST Date: Sat, 12 Mar 94 17:28:27 EST Message-Id: <9403122228.AA12316@mailserv-D.ftp.com> To: alun@internet.wst.com Subject: Re: Does "initially" mean anything? From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: rcq@ftp.com, winsock-hackers@sunsite.unc.edu Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Sat Mar 12 17:28:18 1994] Originating-Client: oysters.ftp.com Content-Length: 2955 > > Perhaps it should be re-written given the confusion evidenced, > > but it is valid. It refers to when WSAAsyncSelect() is called, > > anytime it's called (i.e. not just the first time it's called). > > So it sounds as though this could provide a solution to one of my > current problems with half the winsock stacks in the world! The > problem, quite simply stated, is that I find WSAENOBUFS returned from > WSAGetLastError() after a send() on a non-blocking socket. ZING! Ok, I know we're guilty of this Alun, and you know I promised to fix it RSN. > I understand that this is in an effort to give me more information > than a simple WSAEWOULDBLOCK, but it doesn't send me the signals when > the buffer space is finally available (or whatever caused the NOBUFS > is over). We were misguided in thinking that developers would want to have some finer resolution on the error returned, but we've come around. Now we realize it makes for a simpler program if a send() or sendto() fails with WSAEWOULDBLOCK if there's any buffer related problem (so the app can rely on the FD_WRITE upcall). Live and learn. > If I now re-run the WSAAsyncSelect() call if I get anything > but WSAEWOULDBLOCK, then this should re-send me a FD_WRITE message > when the socket can be written to again. > > Am I right? Well, yes, kind of. I can't speak for other vendors, but I can tell you exactly how our WinSock DLL works. We'll send an FD_WRITE message to you immediately upon your call to WSAAsyncSelect() if the TCP socket currently has a valid connection. We don't actually check if there's buffer space available, because--unfortunately--our stack doesn't have a mechanism to check or report buffer availability ...short of trying to send(). If it works with this method with our DLL, it works because by the time we're done processing your second WSAAsyncSelect() call, the condition that caused the error has cleared up. This is *not* a recommended approach, however. The main reason our send() or sendto() fail with WSAENOBUFS is if you have some kind of configuration problem. That's why we chose to give it to you. So my first recommendation (for ours anyway) is to check the config (specifically the MinimumCopySpace setting in [386Enh] section of your SYSTEM.INI file should be cranked up from the minimum of 28 ...up to 64, if I remember right). Given that this is a problem with ~50% of the universe, the next suggestion is to use a Windows timer. Retry the send() when the timjer goes off. Of course, you always want to leave an out for the user (preferably a threshhold after which you give up, realizing it's fruitless to keep trying). Maybe at that point you could suggest to the user that they look at the configuration (among other possibilities). Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Mon Mar 14 03:46:04 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20761; Sun, 13 Mar 1994 17:33:17 -0500 Received: by usage.csd.unsw.OZ.AU id AA18683 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 14 Mar 1994 08:33:34 +1000 Received: by atlas (4.1/1.35) id AA28300; Mon, 14 Mar 94 08:46:04 EST Message-Id: <9403132246.AA28300@atlas> From: paul@atlas.abccomp.oz.au Date: Mon, 14 Mar 1994 08:46:04 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: hall@cs.sfu.ca, Multiple recipients of list Subject: Re: What does WSANO_DATA mean Thus expounded Gary Hall on Mar 12, 4:26am: /-------------------- |I have a call to gethostbyaddr that is failing with the WSANO_DATA error. |The error description is: "Valid name, no data record of requested type". |I am at a loss to know what this means. Can anyone enlighten me? It means the name itself was found in the database (either the HOSTS file or from a DNS server) but there was no 'A' (Address) record associated with the name. This can happen, for example, with sites that aren't directly connected with the internet (so have no IP number that you can reach) but have an MX (Mail eXchanger) record with the name of a machine that is, so email can be routed through the other machine. If you are resolvig from a hosts file, make sure there is an address associated with the name. If you are resolving from a DNS server, ask your administrator to find out what records _do_ exist for the host you are looking for. You should get the same answer trying to resolve 'atlas.abccomp.oz.au' as well - we aren't directly connected, so our DNS entry does not have an 'A' record, but there is an MX record directing email to munnari. -- 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 jnlin@netrd.net.tw Mon Mar 14 02:42:58 1994 Received: from netrd.net.tw by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03089; Sun, 13 Mar 1994 19:43:08 -0500 Received: by netrd.net.tw (4.1/SMI-4.1) id AA21467; Mon, 14 Mar 94 08:42:58 CST Date: Mon, 14 Mar 94 08:42:58 CST From: jnlin@netrd.net.tw (Jyun Naih Lin) Message-Id: <9403140042.AA21467@netrd.net.tw> To: winsock-hackers@sunsite.unc.edu Subject: Questions about Winsock and Netmanage Chameleon >From natale@acec.com Fri Mar 11 02:38:59 1994 Return-Path: Received: from uu9.psi.com by netrd.net.tw (4.1/SMI-4.1) id AA06182; Fri, 11 Mar 94 02:38:28 CST Received: from acec.com by uu9.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA01915 for jnlin@netrd.net.tw; Thu, 10 Mar 94 13:39:25 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13623; Thu, 10 Mar 1994 13:35:26 -0500 Date: Thu, 10 Mar 1994 13:34:48 EST From: Bob Natale Subject: Re: Questions and need answers To: jnlin@netrd.net.tw Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO > From: Jyun Naih Lin > Date: Thu, 25 Nov 1993 21:32:48 -0500 > Subject: Questions and need answers > To: Multiple recipients of list Hi Jyun Naih Lin, > I have some questions: Did you receive answers to these? If so, can you forward me a copy or summary, please? If not, maybe you should re-post them to winsock-hackers@sunsite.unc.edu. You might be (a little) more likely to get a response from to these questions in that forum. > (1) When I call getsockname() or getpeername() to get local ip or remote > ip and port. The return value of the port (sin_port) should be network byte > order or host byte order? > > I use the Winsock.DLL of "Netmanage Company". Their Winsock.DLL returns > network byte order in getsockname(), but host byte order in getpeername(). > > (2) Could an UDP socket send data before it binds to an address? > > I create an UDP socket and then call WSAAsyncSelect() to set FD_READ, > FD_WRITE, etc, to the UDP socket. Before I call bind(), Netmanage's Winsock.DLL > post a FD_WRITE message to my AP. Is it right? > > (3) If I call WSAAsyncSelect() to set FD_CONNECT, FD_CLOSE, etc to a TCP > socket. When I call connect() to connect the TCP socket to an address which > has no socket listening. What event should I receive from Winsock.DLL? > FD_CONNECT or FD_CLOSE? > > I receive FD_CLOSE event from Netmanage's Winsock.DLL. Is it right? > I think it should be FD_CONNECT and the error should be set in the lParam. > > (4) What kind of buffer should I prepare before I call WSAAsyncGetXbyY()? > I should allocate a large block and pass it to the system, or I should allocate > spaces for each fields (such as name, aliases, etc). Could anyone give me an > example? > > I call Netmanage's WSAAsyncGetXByY() and it cause a GPF in NMPCIP.DLL. > > (5) According to the definition of Winsock Ver. 1.1. TCP socket can use > sendto() and recvfrom(), but Netmanage's Winsock.DLL disallows the user to > use sendto()and recvfrom() on the TCP socket. Why? > > I do some unit tests in Netmanage's Winsock.DLL and find that they do > NOT check many conditions and cause errors. The product seems not to be desinged > fully compactable with Winsock Ver. 1.1 ..... > > Thank you for your assistance. > > Lin Jyun-Naih > ---------------------- jnlin@netrd.net.tw ------------------- BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com From natale@acec.com Mon Mar 14 05:24:31 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13974; Mon, 14 Mar 1994 10:26:52 -0500 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA08939 for winsock-hackers@sunsite.unc.edu; Mon, 14 Mar 94 10:26:25 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA24265; Mon, 14 Mar 1994 10:25:40 -0500 Date: Mon, 14 Mar 1994 10:24:31 EST From: Bob Natale Subject: Re: WSAAsyncSelect() reenab To: johnt@unipalm.co.uk Cc: Multiple recipients of list Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: John Taylor > Date: Mon, 14 Mar 1994 01:39:37 -0500 > Subject: Re: WSAAsyncSelect() reenab Hi John, > On Sat, 12 Mar 94 07:47:20 GMT Bob Natale Wrote: > > Yes...this is absolutely true. I am constantly (...repeatedly, > > actually) amazed at how many programmers I encounter who have > > a mental block in this regard. Every new programmer we have put > > on a WinSock app (except for one person over the past two years) > > has started off employing a multiple WSAAsyncSelect() strategy > > where a single one at the outset would have sufficed. They > > usually reach this stage after we ween them from the "blocking > > mode" stage! :-) A lot of these folks--who are typically very > > sharp overall--are wanna-bees in the "Windows is brain-dead; > > UNIX is elegant" camp...is there more than just a correlation at > > work here? > [After having battled with Windows for several years, and still > thinking Unix is better in ALL respects(Smaller, quicker, more portable, > easier to program ...). I couldn't resist replying to this :-) ] I am very glad you did... :-) An initial aside on your UNIX qualities: - Smaller ... have you checked the sizes of UNIX apps compiled on RISC machines, with similar functionality to the major Windows apps? Have you checked the RAM and swap space requirements on most UNIX workstations these days, just to run even one console-centric app like SunNet Manager? [Rhetorical questions...I'm sure you have...my personal assessment of the answers is 'too big' ($$$).] :-) - Quicker ...X apps are faster (and/or use less resources) than Windows apps... I don't think so. :-) - More Portable ...You have to port? :-) > After having admitted that most trained programmers find using > Windows not intuitive. Maybe that 'training' does something to retard intuition, imagination, or at least the understanding that externalities might change...and the 'trained programmers' might have to change as a result. > (The only person who could understand the interface hadn't > been trained in good programming techniques) Having been doing this for almost 25 years myself--both in the hands-on and managerial roles--I am convinced that 'good programming techniques' are negative assets (i.e., liabilities) in the absence of a more generalized kind of training in work-world realities. I have not observed that formal training in programming techniques--prior to the accumulation of significant successful on-the-job experience--is a strong positive indicator of success at all. > Why do you find it surprising that so many people conclude that > "Windows is brain-dead". - Thousands of attractive, functional running Windows applications --most extremely more ergonomic and feature-rich than most UNIX apps. - Millions of users of those apps on a daily basis--most of whom have little to no formal computer training. - The backing of major organizations (whose technical and engineering skills I personally trust in extending Windows in other domains) --here I'm thinking of, say, the telco/PBX world and TAPI and the printer/copier people and whatever they're calling the concept of maing Windows the interface to 'everyday' office and home devices. - And, yes, lest we forget, all the results measured in $$$. > If 100 trained engineers said, they could understand why a bridge > doesn't collapse, and an untrained salesman said it looked fine. I assume you mean the engineers said that they could _not_ understand why the bridge doesn't collapse... > Would you think that there was something wrong with the bridge, or the > salesman new better than the trained engineers ? If 42-million (give or take a few) cars and trucks and buses use the bridge every day to get where they want to go, I'd suggest the engineers aren't looking in the right place to achieve an understanding of why the bridge works. And this is the crux of the problem...most of them would not know how to go about 'discovering' the new model... > My bet goes with the Engineers :-) If you're going to the May Interop in Las Vegas, take that salesuy with you! :-) Very cordially yours, BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com From rcq@mailserv-D.ftp.com Mon Mar 14 06:16:22 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA21324; Mon, 14 Mar 1994 11:16:57 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 14 Mar 1994 11:16:56 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19133; Mon, 14 Mar 94 11:16:22 EST Date: Mon, 14 Mar 94 11:16:22 EST Message-Id: <9403141616.AA19133@mailserv-D.ftp.com> To: johnt@unipalm.co.uk Subject: Re: WSAAsyncSelect() reenab From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: Multiple recipients of list Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Mar 14 11:16:19 1994] Originating-Client: oysters.ftp.com Content-Length: 567 > If 100 trained engineers said, they could understand why a bridge doesn't > collapse, and an untrained salesman said it looked fine. > Would you think that there was something wrong with the bridge, or the > salesman new better than the trained engineers ? If 2 million of the salesman's customers say that a bridge is what they want, does it really matter what offends the high-minded engineers? :) never say never, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From Abtin_Assadi@3mail.3com.com Mon Mar 14 01:56:00 1994 Received: from relay2.UU.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA07329; Mon, 14 Mar 1994 13:08:34 -0500 Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhfk28327; Mon, 14 Mar 94 13:08:06 -0500 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA19548; Mon, 14 Mar 94 10:08:22 PST Received: by gw.3Com.COM id AA10580 (5.65c/IDA-1.4.4 for winsock-hackers@sunsite.unc.edu); Mon, 14 Mar 1994 10:07:47 -0800 Date: Mon, 14 Mar 94 09:56 PST From: Abtin_Assadi@3mail.3com.com Subject: Unsubscribe To: winsock-hackers@sunsite.unc.edu Cc: Abtin_Assadi@3mail.3com.com Message-Id: <940314.101103@3Mail.3Com.COM> Forwarded: Message from {mikek@vironix.co.za}:ugate:3Com of 3-12-94 Please unsubscribe From tmima@netmanage.com Mon Mar 14 02:11:40 1994 Received: from relay2.UU.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11971; Mon, 14 Mar 1994 13:38:04 -0500 Received: from netmanage.com (via netman-gate.netmanage.com) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhfm07806; Mon, 14 Mar 94 13:35:06 -0500 Received: from chamber2.netmanage.com ([156.27.3.126]) by netmanage.com (4.1/NetManage-1.0) id AA23254; Mon, 14 Mar 94 10:26:00 PST Date: Mon, 14 Mar 94 10:11:40 PST From: Tmima Koren Subject: RE: Questions about Winsock and Netmanage Chameleon To: jnlin@netrd.net.tw, natale@acec.com, winsock-hackers@sunsite.unc.edu X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please check our last release, 4.0, to see which questions are still applicable. You can get a demo copy from ftp.netmanage.com Tmima ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tmima@netmanage.com (Tmima Koren) (408)973-7171 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----------Original Message---------- >From natale@acec.com Fri Mar 11 02:38:59 1994 Return-Path: Received: from uu9.psi.com by netrd.net.tw (4.1/SMI-4.1) id AA06182; Fri, 11 Mar 94 02:38:28 CST Received: from acec.com by uu9.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA01915 for jnlin@netrd.net.tw; Thu, 10 Mar 94 13:39:25 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13623; Thu, 10 Mar 1994 13:35:26 -0500 Date: Thu, 10 Mar 1994 13:34:48 EST From: Bob Natale Subject: Re: Questions and need answers To: jnlin@netrd.net.tw Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO > From: Jyun Naih Lin > Date: Thu, 25 Nov 1993 21:32:48 -0500 > Subject: Questions and need answers > To: Multiple recipients of list Hi Jyun Naih Lin, > I have some questions: Did you receive answers to these? If so, can you forward me a copy or summary, please? If not, maybe you should re-post them to winsock-hackers@sunsite.unc.edu. You might be (a little) more likely to get a response from to these questions in that forum. > (1) When I call getsockname() or getpeername() to get local ip or remote > ip and port. The return value of the port (sin_port) should be network byte > order or host byte order? > > I use the Winsock.DLL of "Netmanage Company". Their Winsock.DLL returns > network byte order in getsockname(), but host byte order in getpeername(). > > (2) Could an UDP socket send data before it binds to an address? > > I create an UDP socket and then call WSAAsyncSelect() to set FD_READ, > FD_WRITE, etc, to the UDP socket. Before I call bind(), Netmanage's Winsock.DLL > post a FD_WRITE message to my AP. Is it right? > > (3) If I call WSAAsyncSelect() to set FD_CONNECT, FD_CLOSE, etc to a TCP > socket. When I call connect() to connect the TCP socket to an address which > has no socket listening. What event should I receive from Winsock.DLL? > FD_CONNECT or FD_CLOSE? > > I receive FD_CLOSE event from Netmanage's Winsock.DLL. Is it right? > I think it should be FD_CONNECT and the error should be set in the lParam. > > (4) What kind of buffer should I prepare before I call WSAAsyncGetXbyY()? > I should allocate a large block and pass it to the system, or I should allocate > spaces for each fields (such as name, aliases, etc). Could anyone give me an > example? > > I call Netmanage's WSAAsyncGetXByY() and it cause a GPF in NMPCIP.DLL. > > (5) According to the definition of Winsock Ver. 1.1. TCP socket can use > sendto() and recvfrom(), but Netmanage's Winsock.DLL disallows the user to > use sendto()and recvfrom() on the TCP socket. Why? > > I do some unit tests in Netmanage's Winsock.DLL and find that they do > NOT check many conditions and cause errors. The product seems not to be desinged > fully compactable with Winsock Ver. 1.1 ..... > > Thank you for your assistance. > > Lin Jyun-Naih > ---------------------- jnlin@netrd.net.tw ------------------- BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------End of Original Message---------- From vance@netcom.com Mon Mar 14 04:15:39 1994 Received: from netcom8.netcom.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03279; Mon, 14 Mar 1994 15:47:02 -0500 Received: from localhost by netcom8.netcom.com (8.6.4/SMI-4.1/Netcom) id MAA11227; Mon, 14 Mar 1994 12:15:39 -0800 Date: Mon, 14 Mar 1994 12:15:39 -0800 From: vance@netcom.com (Vance Gloster) Message-Id: <199403142015.MAA11227@netcom8.netcom.com> To: Abtin_Assadi@3mail.3com.com Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <940314.101103@3Mail.3Com.COM> (Abtin_Assadi@3mail.3com.com) Subject: Re: Unsubscribe Here are subscribe and unsubscribe instructions for win3-l. I think they will work for winsock-hackers if you send the appropriate command to listserv@sunsite.unc.edu. -Vance Gloster vance@netcom.com To subscribe to the Win3-L maillist send a message containing ONLY the following text to listserv@uicvm.uic.edu. SUBSCRIBE WIN3-L DO NOT send this message to win3-l@uicvm.uic.edu or you will get lots of angry mail (Win3-L has lots of people who read it). To unsubscribe send a message containing ONLY UNSUBSCRIBE WIN3-L to listserv@uicvm.uic.edu (once again NOT win3-l@uicvm.uic.edu). To temporarily stop Win3-L (while on vacation for instance) send a message containing ONLY SET NOMAIL to listserv@uicvm.uic.edu (once again NOT win3-l@uicvm.uic.edu). When you want to resume send a message containing only SET MAIL to listserv@uicvm.uic.edu (once again NOT win3-l@uicvm.uic.edu). From Robell_Alan/cup_openmail_hpiala2@hpiala2.cup.hp.com Mon Mar 14 05:58:30 1994 Received: from hp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA14551; Mon, 14 Mar 1994 17:03:09 -0500 Received: from hpiala2.cup.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA19783; Mon, 14 Mar 1994 14:03:04 -0800 Received: from by hpiala2.cup.hp.com with SMTP (1.37.109.8/16.2) id AA05843; Mon, 14 Mar 1994 13:58:59 -0800 From: Robell_Alan/cup_openmail_hpiala2@hpiala2.cup.hp.com X-Openmail-Hops: 1 Date: Mon, 14 Mar 94 13:58:30 -0800 Message-Id: Subject: unsubscribe To: winsock-hackers@SunSITE.Unc.EDU From paul@atlas.dev.abccomp.oz.au Tue Mar 15 04:40:10 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA26541; Mon, 14 Mar 1994 18:28:08 -0500 Received: by usage.csd.unsw.OZ.AU id AA09062 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 15 Mar 1994 09:27:39 +1000 Received: by atlas (4.1/1.35) id AA03129; Tue, 15 Mar 94 09:40:11 EST Message-Id: <9403142340.AA03129@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 15 Mar 1994 09:40:10 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com, Multiple recipients of list Subject: Re: What does WSANO_DATA mean Thus expounded Bob Quinn on Mar 14, 2:12am: /-------------------- |> I have a call to gethostbyaddr that is failing with the WSANO_DATA error. |> The error description is: "Valid name, no data record of requested type". |> I am at a loss to know what this means. Can anyone enlighten me? | |In Berkeley-ese it means "Valid name, no data reocrd of requested |type." Translated to Windows Sockets-ese, after gethostbyname() |fails this means "I'm sure this is a very nice hostname, but we |can't find any record of it to give you an IP address back." | |Bottom line: that hostname (or IP address, for gethostbyaddr()) |is not in your local hosttable (if you have one configured), and/or |not known by your Domain Name Server (if you have one configured and |responding). Sorry, Bob, I can't agree with this. This condition (name not found in hosttable or DNS) should IMHO return WSAHOST_NOT_FOUND or WSATRY_AGAIN (for non-authoritative host-not-found from DNS server), _not_ WSANO_DATA. WSANO_DATA should mean the name _was_ found in the database, but it had no address record associated with it - such as a hostname that has an MX record, not an A record, in the DNS. I beleive the explanations for each error code in the descriptions for all the getXXXbyYYY and WSAAsyncGetXXXbyYYY function calls are quite clear in this regard. |Regards, |-- | Bob Quinn rcq@ftp.com | FTP Software, Inc. No. Andover, MA | \--------------------- {end} -- 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 bruceo@loki.isc-br.com Mon Mar 14 08:03:21 1994 Received: from loki.isc-br.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00880; Mon, 14 Mar 1994 19:03:47 -0500 Received: by loki.isc-br.com (/\==/\ Smail3.1.21.1 #21.14) id ; Mon, 14 Mar 94 16:03 PST Message-Id: Subject: unsubscribe To: winsock-hackers@sunsite.unc.edu Date: Mon, 14 Mar 94 16:03:21 PST From: Bruce Oscarson X-Mailer: ELM [version 2.3 PL11] please unsubscribe From rcq@mailserv-D.ftp.com Mon Mar 14 18:22:49 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA02802; Mon, 14 Mar 1994 23:23:33 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 14 Mar 1994 23:23:25 -0500 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA26968; Mon, 14 Mar 94 23:22:49 EST Date: Mon, 14 Mar 94 23:22:49 EST Message-Id: <9403150422.AA26968@mailserv-D.ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: What does WSANO_DATA mean From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: rcq@ftp.com, Multiple recipients of list Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Mar 14 23:22:37 1994] Originating-Client: hurricane.ftp.com Content-Length: 2579 >|>I have a call to gethostbyaddr that is failing with the WSANO_DATA error. >|>The error description is: "Valid name, no data record of requested type". >|>I am at a loss to know what this means. Can anyone enlighten me? >| >|In Berkeley-ese it means "Valid name, no data reocrd of requested >|type." Translated to Windows Sockets-ese, after gethostbyname() >|fails this means "I'm sure this is a very nice hostname, but we >|can't find any record of it to give you an IP address back." >| >|Bottom line: that hostname (or IP address, for gethostbyaddr()) >|is not in your local hosttable (if you have one configured), and/or >|not known by your Domain Name Server (if you have one configured and >|responding). > >Sorry, Bob, I can't agree with this. This condition (name not found in >hosttable or DNS) should IMHO return WSAHOST_NOT_FOUND or WSATRY_AGAIN >(for non-authoritative host-not-found from DNS server), _not_ WSANO_DATA. >WSANO_DATA should mean the name _was_ found in the database, but it had no >address record associated with it - such as a hostname that has an MX record, >not an A record, in the DNS. I'll buy that, thanks for the correction Paul. What about CNAME and PTR records? Do they relate at all to the success or failure (and error values) after a hostname or address lookup? >I beleive the explanations for each error code in the descriptions for >all the getXXXbyYYY and WSAAsyncGetXXXbyYYY function calls are quite clear >in this regard. ...my turn to apologize for disagreeing :) The WinSock spec doesn't make any reference to Domain Name System (DNS), let alone MX or A records. Here are some other questions: - the h_name field in the hostent structure is described on page 60 as the "Official name of the host (PC)". Does this mean the canonical name? What's this about a PC? - where does the database information come from? It can be a local hosttable as well as a DNS server, and what about NIS? - what type of information does it need to succeed (e.g. is a DNS 'A'ddress record required)? To stir the waters a bit more, notice that the service and protocol database query functions can also fail with WSANO_DATA. These have the same textual description: "Valid name, no data record of requested type," but your very reasonable explanation does not apply well since there is no alternative error analogous to the hostname WSAHOST_NOT_FOUND. Isn't this fun? -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Tue Mar 15 11:14:51 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12532; Tue, 15 Mar 1994 01:02:44 -0500 Received: by usage.csd.unsw.OZ.AU id AA27657 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Tue, 15 Mar 1994 16:02:22 +1000 Received: by atlas (4.1/1.35) id AA05164; Tue, 15 Mar 94 16:14:52 EST Message-Id: <9403150614.AA05164@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 15 Mar 1994 16:14:51 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com Subject: Re: What does WSANO_DATA mean Cc: Multiple recipients of list Thus expounded Bob Quinn on Mar 14,11:22pm: /-------------------- | |>|>I have a call to gethostbyaddr that is failing with the WSANO_DATA error. |>|>The error description is: "Valid name, no data record of requested type". |>|>I am at a loss to know what this means. Can anyone enlighten me? |>| |>|In Berkeley-ese it means "Valid name, no data reocrd of requested |>|type." Translated to Windows Sockets-ese, after gethostbyname() |>|fails this means "I'm sure this is a very nice hostname, but we |>|can't find any record of it to give you an IP address back." |>| |>|Bottom line: that hostname (or IP address, for gethostbyaddr()) |>|is not in your local hosttable (if you have one configured), and/or |>|not known by your Domain Name Server (if you have one configured and |>|responding). |> |>Sorry, Bob, I can't agree with this. This condition (name not found in |>hosttable or DNS) should IMHO return WSAHOST_NOT_FOUND or WSATRY_AGAIN |>(for non-authoritative host-not-found from DNS server), _not_ WSANO_DATA. |>WSANO_DATA should mean the name _was_ found in the database, but it had no |>address record associated with it - such as a hostname that has an MX record, |>not an A record, in the DNS. | |I'll buy that, thanks for the correction Paul. What about CNAME and |PTR records? Do they relate at all to the success or failure (and |error values) after a hostname or address lookup? That depends on your implementation, I guess. Our resolver can do its own recursive queries in the face of CNAMES. Since most implementations will ask the DNS server for a recursive answer, CNAMEs won't be returned to the application, and a PTR record is exactly what you want for a gethostbyaddr() call, anyway. To answer your question, if the underlying DNS code got back a CNAME or PTR, that means the host name itself existed, so the return is still WSANO_DATA. Only if the DNS returns an Authoritative or Non-authoritative Host Not Found would you return WSAHOST_NOT_FOUND or WSATRY_AGAIN respectively. |...my turn to apologize for disagreeing :) | |The WinSock spec doesn't make any reference to Domain Name System |(DNS), let alone MX or A records. Here are some other questions: Why do I let myself be drawn into these discussions with you, Bob? :-) For the Greater Good of a consistent spec., I guess... No, but the WSA error codes mentioned map exactly to the possible replies for a query from a DNS server. Mapping operations in local tables to these values (as you talk about below) is more problematic than mapping DNS replies to them. | - the h_name field in the hostent structure is described on page | 60 as the "Official name of the host (PC)". Does this mean | the canonical name? What's this about a PC? 1) To me it means the canonical name. If using the DNS, its the FQDN that caused the server to return an answer (which is in the DNS reply packet), and if using a hosts file its the first entry after the IP number, if my memory of BSD convention serves correctly. (IPnumber hostname alias1 alias2 alias3 ...) If using the NIS, I'll punt - I know nothing about it ! 2) The 'PC' here is a red herring. It means nothing. I don't know _what_ its doing here - it doesn't appear in the comments against the structure in the WINSOCK.H file! | - where does the database information come from? It can be a | local hosttable as well as a DNS server, and what about NIS? This is implemntation dependent, as mentioned on page 7. Where the information comes from is immaterial. It has to be mapped into a struct hostent, so the error codes have to be mapped into the four WSA error codes for database routines (11001 - 11004), which happen to be the exact returns possible from a DNS server. The fact that only gethostbyYYY() calls might possibly use a DNS server is not relevent. | - what type of information does it need to succeed (e.g. is a DNS | 'A'ddress record required)? For a gethostbyname() query using the DNS, yes. If using a hoststable, I contend you should get back a valid hostent, or WSAHOST_NOT_FOUND - you should only get back WSANO_DATA if there was a line which contained the desired hostname, but which had no IP number at the beginning, which is not a smart way to write a hosts file ! :-) You want me to iterate over every possible combination? :-) for gethostbyname(), if (using DNS) { query 'A' record. if (found) return hostent, else if (nameOK && !'A' record) return WSAENO_DATA; else // hostname not in database return WSAHOST_NOT_FOUND; } else if (using hosttable) ( etc ) |To stir the waters a bit more, notice that the service and protocol |database query functions can also fail with WSANO_DATA. These have |the same textual description: "Valid name, no data record of |requested type," but your very reasonable explanation does not apply |well since there is no alternative error analogous to the hostname |WSAHOST_NOT_FOUND. Maybe we should add an extra error code - WSAENTRY_NOT_FOUND for services and protocols routines ? :-/ | |Isn't this fun? Gangs of fun!. So Bob, what does FTP's getprotobyname return if passed a NULL pointer or a valid pointer to a 0-length string? Notice too, that getprotobynumber and getservbyport also list WSANODATA "Valid name, no data record..." and the argument is not even a 'name'! Isn't this why we're looking at v2.0? - I don't think _anyone_ is saying the v1.1 spec is inconsistency free, although this discussion may have just crossed the border of common sense.... 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 meunier@capsogeti.fr Tue Mar 15 10:20:59 1994 Received: from chenas.inria.fr by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00708; Tue, 15 Mar 1994 03:22:08 -0500 Received: from csinn (csinn.capsogeti.fr) by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA10165; Tue, 15 Mar 1994 09:21:53 +0100 (MET) Received: from eniac by csinn (4.1/CSI2.2) id AA06342; Tue, 15 Mar 94 09:21:22 +0100 Return-Path: Received: by eniac (4.1/CSI2.2) id AA16990; Tue, 15 Mar 94 09:20:59 +0100 Date: Tue, 15 Mar 94 09:20:59 +0100 From: Jean-Luc Meunier Message-Id: <9403150820.AA16990@eniac> To: winsock-hackers@sunsite.unc.edu Subject: Unsubscribe Please unsubscribe From johnt@unipalm.co.uk Tue Mar 15 09:01:20 1994 Received: from unipalm.co.uk (unipalm.unipalm.co.uk) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03129; Tue, 15 Mar 1994 03:54:33 -0500 Received: from brimstone.unipalm.co.uk by unipalm.co.uk (4.1/SMI-4.1 (unipalm 1.17)) id AA04186; Tue, 15 Mar 94 08:54:19 GMT Received: from dreft.unipalm.co.uk by brimstone.unipalm.co.uk (4.1/SMI-4.1 brimstone 1.19) id AA06960; Tue, 15 Mar 94 08:54:15 GMT Message-Id: <9403150854.AA06960@brimstone.unipalm.co.uk> Priority: Normal To: Bob Quinn Reply-To: johnt@unipalm.co.uk Cc: winsock-hackers@sunsite.unc.edu Mime-Version: 1.0 From: John Taylor Subject: Re: WSAAsyncSelect() reenab Date: Tue, 15 Mar 94 09:01:20 GMT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"; X-MAPIrenderingpos=0xFFFFFFFF Content-Transfer-Encoding: quoted-printable On Mon, 14 Mar 94 16:16:22 GMT Bob Quinn Wrote: > > If 100 trained engineers said, they could understand why a bridge = doesn't > > collapse, and an untrained salesman said it looked fine. > > Would you think that there was something wrong with the bridge, or = the > > salesman new better than the trained engineers ? > > If 2 million of the salesman's customers say that a bridge is what they= > want, does it really matter what offends the high-minded engineers? = :) > Yes, because they will get blamed when it falls down ! JohnT [EOT] End Of Thread. I'm sure that this could carry on forever - but it's not to everyone tast= es. From andy@visionware.co.uk Mon Mar 14 08:43:15 1994 Received: from uucphost.visionware.co.uk (vision.visionware.co.uk) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA04375; Tue, 15 Mar 1994 04:08:59 -0500 Received: from toast.visionware.co.uk by uucphost.visionware.co.uk (5.59/5.930520) id AA02598; Tue, 15 Mar 94 09:08:52 GMT Received: by toast.visionware.co.uk (5.59/smail2.5/10-15-90) id AA04039; Mon, 14 Mar 94 08:43:23 GMT From: andy@visionware.co.uk (Andy Shaw) Message-Id: <9403140843.AA04039@toast.visionware.co.uk> Subject: unsubscribe To: winsock-hackers@sunsite.unc.edu Date: Mon, 14 Mar 94 8:43:15 GMT X-Mailer: ELM [version 2.2 PL16] From marcn@ncsa.uiuc.edu Tue Mar 15 01:47:44 1994 Received: from newton.ncsa.uiuc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24090; Tue, 15 Mar 1994 08:47:44 -0500 Received: from isr0157.urh.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA08414 (5.65a/IDA-1.4.2 for winsock-hackers@sunsite.unc.edu); Tue, 15 Mar 94 07:47:40 -0600 Message-Id: <9403151347.AA08414@newton.ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Mar 1994 07:47:44 -0600 To: winsock-hackers@sunsite.unc.edu From: marcn@ncsa.uiuc.edu (Marc Nardulli) Subject: unsubscribe From spencer@DeGaulle.HIL.UNB.Ca Tue Mar 15 06:57:31 1994 Received: from unb.ca (hermes.csd.unb.ca) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00575; Tue, 15 Mar 1994 10:00:29 -0500 Received: from DeGaulle.HIL.UNB.Ca by unb.ca (4.1/SMI-4.1-940224-08:05) id AA00294; Tue, 15 Mar 94 11:00:20 AST Received: by DeGaulle.HIL.UNB.Ca (5.0/SMI-SVR4-930825-08:05) id AA06329; Tue, 15 Mar 94 10:57:33 AST Date: Tue, 15 Mar 1994 10:57:31 -0400 (AST) From: "Dwight E. Spencer" Subject: Re: Unsubscribe To: Jean-Luc Meunier Cc: Multiple recipients of list In-Reply-To: <9403150820.AA16990@eniac> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 776 for those of you trying to unsubscribe, read the first email you recieved from the listserver.. its:... yourprommpt[~] {whoami.xx}% mail listserv@sunsite.unc.edu (no subject) unsubscribe listname .. and you're off the list. dwight. ---------------------------------------------------------------------------- Dwight Ellis Spencer Computing Services Department (506) 453-4573 University New Brunswick Fredericton, NB, Canada Harriet Irving Library (506) 453-4740 "Ask me for help?? What in &^%$&^%$ makes you think I know the answer!! " ---------------------------------------------------------------------------- From rcq@mailserv-D.ftp.com Tue Mar 15 06:08:06 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12443; Tue, 15 Mar 1994 11:08:43 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 15 Mar 1994 11:08:42 -0500 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01052; Tue, 15 Mar 94 11:08:06 EST Date: Tue, 15 Mar 94 11:08:06 EST Message-Id: <9403151608.AA01052@mailserv-D.ftp.com> To: paul@atlas.abccomp.oz.au Subject: Re: What does WSANO_DATA mean From: rcq@ftp.com (Bob Quinn) Reply-To: rcq@ftp.com Cc: winsock-hackers@sunsite.unc.edu Sender: rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Tue Mar 15 11:07:59 1994] Originating-Client: hurricane.ftp.com Content-Length: 1935 > Why do I let myself be drawn into these discussions with you, Bob? :-) > For the Greater Good of a consistent spec., I guess... I *really* appreciate your patience and thoroughness, Paul. And I'm sure I'm not alone. Unfortunately, our stack doesn't provide return codes to give the level of resolution to differentiate between WSNO_DATA and WSAHOST_NOT_FOUND, so for us it comes down to choosing between the two of them. From the standpoint of most applications, the bottom line is sufficient: resolution failed. Those few applications that really need low-level answers from their DNS server should create their own DNS queries and read the responses (for access to NS, PTR, CNAME, MX, HINFO). Good luck to them finding where to send them, though (since there's no mechanism defined in the WinSock API to find your name server address). Oh well :( > |To stir the waters a bit more, notice that the service and protocol > |database query functions can also fail with WSANO_DATA. These have > |the same textual description: "Valid name, no data record of > |requested type," but your very reasonable explanation does not apply > |well since there is no alternative error analogous to the hostname > |WSAHOST_NOT_FOUND. > > Maybe we should add an extra error code - WSAENTRY_NOT_FOUND for > services and protocols routines ? :-/ Certainly worth considering, although there's something to be said for having only a few possible errors to deal with in an application. Maybe just a better description is in order. > Gangs of fun!. So Bob, what does FTP's getprotobyname return if passed > a NULL pointer or a valid pointer to a 0-length string? WSANO_DATA. I just looked at the WSAT serv.tst script for validation, but it doesn't test with these conditions. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From pbh@MIT.EDU Tue Mar 15 13:13:54 1994 Received: from MIT.EDU (MIT.MIT.EDU) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA02236; Tue, 15 Mar 1994 13:13:54 -0500 Received: from ASHPOOL.MIT.EDU by MIT.EDU with SMTP id AA23727; Tue, 15 Mar 94 13:13:52 EST Message-Id: <9403151813.AA23727@MIT.EDU> To: Multiple recipients of list Subject: Re: What does WSANO_DATA mean Date: Tue, 15 Mar 94 13:13:51 From: pbh@MIT.EDU >Those few applications that really need low-level answers from their >DNS server should create their own DNS queries and read the responses >(for access to NS, PTR, CNAME, MX, HINFO). Good luck to them finding >where to send them, though (since there's no mechanism defined in the >WinSock API to find your name server address). Oh well :( This reminds me of the early discussions surrounding getxxxbyxx when winsock was being defined. Many vendors didn't have DNS support in their current stacks so they didn't want these functions defined in the spec. The final compromise was to have the functions defined but allow vendors to have them use either DNS or a local host file. Market realities have driven most vendors to support DNS rather than just local host files. Rumor has it that even the final holdouts will offer full DNS support in their next release. Vendors will find more and more applications need access to res_mkquery() because they need to access specialized information. Very large sites are already using options like Hesiod to dynamically reconfigure resources. The Hesiod support is simply added if the API would support res_mkquery(). If you think only specialized application need this, think again. Our mail clients want to obtain the MX record for mit.edu when sending mail via SMTP. This allows our network to have a redundant mail hub. Our mail clients also make a Hesiod query to find out which POP3 server to use when a user incorporates mail. We currently have three POP3 server handling about 150,000 deliveries per day. In the next few months we will be ading a fourth. At that time we will run a database update that will move users mailboxes around to perform load balancing. Mail clients that can make a Hesiod query will have no problems will this. Users will never know that their mailbox moved. Most users of Eudora will find that they can no longer fetch mail until they find out where they have been moved to and then manually reconfigure thier software. 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? From owner-classm-l@BROWNVM.BROWN.EDU Mon Mar 14 14:32:00 1994 Received: from ti.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03747; Tue, 15 Mar 1994 13:24:45 -0500 Received: from itg.ti.com ([128.247.93.50]) by ti.com with SMTP (5.65c/LAI-3.2) id AA19439; Tue, 15 Mar 1994 12:28:32 -0600 Received: from DSKMGWS2.ITG.TI.COM by itg.ti.com (4.1/ITG-1.1) id AA07574; Tue, 15 Mar 94 12:23:32 CST Message-Id: <9403151823.AA07574@itg.ti.com> From: owner-classm-l@BROWNVM.BROWN.EDU (Monkman, Martin) Date: Mon, 14 Mar 1994 20:32 CST To: CLASSM-L@BROWNVM.brown.edu Subject: Re: American West History (was Lumberjacks) Richard G. Estock wrote in response to first Arj >>> the 12th century Charles Bridge in Prague >>> cannot, fortunately, be compared to Highway 101's Paul >>> Bunion with his 30 Foot Blue Ox near Klamath. Pace, PB. >>> Arj and then Mary Kay >>Oh but I think it can, symbols of a perfect contrast of >>societies and taste! The American West is essentially without >>history by comparison to so many parts of the world, so it is >>interesting to see what is seized upon for mythology and >>symbols in this virgin land, and how those symbols are used. >>This statuary has to be seen to be believed, such ugliness >>constructed in celebration of forests far older than the >>Prague Bridge. To me it is pretty amazing, but I am an >>interloper to the area. by saying >THE AMERICAN WEST WITHOUT HISTORY?!?!?!? Open your eyes! Go to the >library! Read some books! You will find more about the history >of the American West then you will find on the history of England! The flippant answer is *Depends on the library*, but let's be honest ... English history has been tracked since roughly 1 A.D. (with Roman records) and the American (and Canadian) history have to rely on oral myth and tradition prior to about 1500. When we start tracking the history of *the west* depends on where we draw the line; some would say the Mississippi, others the continental divide ... either way, it is much more recently! >And the reference to England is apt in that some of the classic >19th century books on the American (and Canadian) West were written >by none other than Englishmen! True enough ... but let's not forget the role the Spanish and French played in the history of the area. >The history of the American West is >so rich as to nearly overwhelm all else. What may have happened >in a thousand years elsewhere occurred in the American West in less >than a hundred. Huh? Just because the timing of the settlement of North America by Europeans happened to coincide with some profound technological and social innovations (which, not coincidentally, happened to make that settlement possible in the first place...) does not mean that there is *more history*. >Sorry, but your observation and conclusion above are simply not true. >You cannot extend a commercial manifestation of a children's tale >as a representation of that society grasping for symbols. I do believe we can ... those pioneers were too busy pioneerin' to bother thinking From MNG@us.oracle.com Tue Mar 15 02:39:18 1994 Received: from gatekeeper.us.oracle.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05960; Tue, 15 Mar 1994 13:38:09 -0500 Received: from prodpyr1.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id KAA15930; Tue, 15 Mar 1994 10:38:07 -0800 Received: by prodpyr1.us.oracle.com (Oracle 1.12/37.7) id AA17784; Tue, 15 Mar 94 10:39:18 PST Message-Id: <9403151839.AA17784@prodpyr1.us.oracle.com> Date: Tue, 15 Mar 94 10:39:18 PST From: "Mason S. Ng@oracle.com" To: winsock-hackers@sunsite.unc.edu Subject: unsubscribe Please unsubscribe!! Thanks.... Mason S. Ng Oracle Media Server (415)506-2187 5OP425 mng@us.oracle.com From dob@tis.inel.gov Tue Mar 15 06:01:22 1994 Received: from mica.inel.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA22350; Tue, 15 Mar 1994 15:00:35 -0500 Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov (4.1/INEL-MH-10.0) id AA29273; Tue, 15 Mar 94 13:00:33 MST Received: by dewey.inel.gov (5.65/INEL-WKS-2.0) id AA28386; Tue, 15 Mar 1994 13:01:22 -0700 Date: Tue, 15 Mar 1994 13:01:22 -0700 Message-Id: <9403152001.AA28386@dewey.inel.gov> From: dob@inel.gov To: oli@inel.gov, coop@inel.gov Cc: winsock-hackers@sunsite.unc.edu Subject: Re: What does WSANO_DATA mean In-Reply-To: <9403151813.AA23727@MIT.EDU> References: <9403151813.AA23727@MIT.EDU> A lonely voice in support of better access to DNS info from within WinSock ... hopefully the wave of the future ("Hi, Future!") Dave pbh@MIT.EDU writes: > > >Those few applications that really need low-level answers from their > >DNS server should create their own DNS queries and read the responses > >(for access to NS, PTR, CNAME, MX, HINFO). Good luck to them finding > >where to send them, though (since there's no mechanism defined in the > >WinSock API to find your name server address). Oh well :( > > This reminds me of the early discussions surrounding getxxxbyxx when > winsock was being defined. Many vendors didn't have DNS support in their > current stacks so they didn't want these functions defined in the spec. The > final compromise was to have the functions defined but allow vendors to > have them use either DNS or a local host file. > > Market realities have driven most vendors to support DNS rather than just > local host files. Rumor has it that even the final holdouts will offer full > DNS support in their next release. > > Vendors will find more and more applications need access to res_mkquery() > because they need to access specialized information. Very large sites are > already using options like Hesiod to dynamically reconfigure resources. The > Hesiod support is simply added if the API would support res_mkquery(). > > If you think only specialized application need this, think again. Our mail > clients want to obtain the MX record for mit.edu when sending mail via > SMTP. This allows our network to have a redundant mail hub. Our mail > clients also make a Hesiod query to find out which POP3 server to use when > a user incorporates mail. We currently have three POP3 server handling > about 150,000 deliveries per day. In the next few months we will be ading a > fourth. At that time we will run a database update that will move users > mailboxes around to perform load balancing. Mail clients that can make a > Hesiod query will have no problems will this. Users will never know that > their mailbox moved. Most users of Eudora will find that they can no longer > fetch mail until they find out where they have been moved to and then > manually reconfigure thier software. > > 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? > From Clark_Breyman.sd@xerox.com Tue Mar 15 04:45:08 1994 Received: from alpha.Xerox.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA02224; Tue, 15 Mar 1994 15:45:50 -0500 Received: from Apollo.sd.xerox.xns by alpha.xerox.com via XNS id <14466(8)>; Tue, 15 Mar 1994 12:45:06 PST X-Ns-Transport-Id: 08003700AD1B8F2C313B Date: Tue, 15 Mar 1994 12:45:08 PST From: Clark_Breyman.sd@xerox.com Subject: unsubscribe To: winsock-hackers@sunsite.unc.edu Reply-To: Clark_Breyman.sd@xerox.com Message-Id: <"15-Mar-94 12:45:08 PST".*.Clark_Breyman.sd@Xerox.com> From rcq@mailserv-D.ftp.com Tue Mar 15 10:48:46 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03001; Tue, 15 Mar 1994 15:49:22 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 15 Mar 1994 15:49:21 -0500 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA05004; Tue, 15 Mar 94 15:48:46 EST Date: Tue, 15 Mar 94 15:48:46 EST Message-Id: <9403152048.AA05004@mailserv-D.ftp.com> To: pbh@MIT.EDU Subject: Re: What does WSANO_DATA mean 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 Tue Mar 15 15:48:40 1994] Originating-Client: hurricane.ftp.com Content-Length: 913 > 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? We have an equivalent available in an external library, but it is not embedded in our stack. I suspect this is common since DNS is an application protocol, not a transport protocol, and because low-level access has not been in great demand. There are other reasons too (related to overhead and stack architecture). But let me turn this around; why don't *you* make sure this API is exposed in the next release of the spec? :-) It takes people with motivation such as yourself to push those you rumor will resist. BTW: Where is the api for res_mkquery() defined? -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From paul@atlas.dev.abccomp.oz.au Wed Mar 16 08:28:20 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA12031; Tue, 15 Mar 1994 22:24:27 -0500 Received: by usage.csd.unsw.OZ.AU id AA09215 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 16 Mar 1994 13:23:20 +1000 Received: by atlas (4.1/1.35) id AA08989; Wed, 16 Mar 94 13:28:21 EST Message-Id: <9403160328.AA08989@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 16 Mar 1994 13:28:20 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: rcq@ftp.com Subject: Re: What does WSANO_DATA mean Cc: winsock-hackers@sunsite.unc.edu Thus expounded Bob Quinn on Mar 15,11:08am: /-------------------- |> Why do I let myself be drawn into these discussions with you, Bob? :-) |> For the Greater Good of a consistent spec., I guess... | |I *really* appreciate your patience and thoroughness, Paul. And I'm |sure I'm not alone. Thanks Bob, its mutual. Its only by getting right down to the nitty-gritty that we can identify areas that need more explanation, so that all implementations can act consistently. Most of these issues never occurred to me while reading the spec. - its only when I came to implement them that I realise some of the loopholes that might allow different implementations to act differently and still 'comply'. |Unfortunately, our stack doesn't provide return codes to give the |level of resolution to differentiate between WSNO_DATA and |WSAHOST_NOT_FOUND, so for us it comes down to choosing between the |two of them. From the standpoint of most applications, the bottom |line is sufficient: resolution failed. Agreed. |Those few applications that really need low-level answers from their |DNS server should create their own DNS queries and read the responses |(for access to NS, PTR, CNAME, MX, HINFO). Good luck to them finding |where to send them, though (since there's no mechanism defined in the |WinSock API to find your name server address). Oh well :( Wasn't it you who pointed out that we can't assume DNS or nameserver anyway (grin) ? Would we then need a mechanism to find the NIS server's address? the (?) server's address? The filename and path of the local hosts file, if it exists? Its not surprising the spec. doesn't define such a mechanism. |> Maybe we should add an extra error code - WSAENTRY_NOT_FOUND for |> services and protocols routines ? :-/ | |Certainly worth considering, although there's something to be said |for having only a few possible errors to deal with in an application. |Maybe just a better description is in order. I agree completely - the suggestion to add another code was (mostly) facetious. Vers. 2 should not gratuitously require changes to V1.1 code, except if a real problem exist. All thats required, really, is a little common sense on the part of us developers. Whether we can rely on that, of course, is quite a different problem! |> Gangs of fun!. So Bob, what does FTP's getprotobyname return if passed |> a NULL pointer or a valid pointer to a 0-length string? | |WSANO_DATA. I just looked at the WSAT serv.tst script for validation, |but it doesn't test with these conditions. So a NULL pointer is a "valid name" ? :-) Surely WSANO_RECOVERY (indicating a FORMERR (format error)) would be better returned here ? Cheers. Whenever you're in the neighbourhood, Bob, please drop in for a beer... -- 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 Mar 16 08:53:28 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA21162; Wed, 16 Mar 1994 02:51:33 -0500 Received: by usage.csd.unsw.OZ.AU id AA09922 (5.65c/IDA-1.4.4); Wed, 16 Mar 1994 13:41:02 +1000 Received: by atlas (4.1/1.35) id AA09082; Wed, 16 Mar 94 13:53:29 EST Message-Id: <9403160353.AA09082@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 16 Mar 1994 13:53:28 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: pbh@mit.edu, Multiple recipients of list Subject: DNS interface (was Re: What does WSANO_DATA mean Thus expounded pbh@MIT.EDU on Mar 15, 1:22pm: /-------------------- | |>Those few applications that really need low-level answers from their |>DNS server should create their own DNS queries and read the responses |>(for access to NS, PTR, CNAME, MX, HINFO). Good luck to them finding |>where to send them, though (since there's no mechanism defined in the |>WinSock API to find your name server address). Oh well :( | |This reminds me of the early discussions surrounding getxxxbyxx when |winsock was being defined. Many vendors didn't have DNS support in their |current stacks so they didn't want these functions defined in the spec. The |final compromise was to have the functions defined but allow vendors to |have them use either DNS or a local host file. | [deletia] |Vendors will find more and more applications need access to res_mkquery() |because they need to access specialized information. Very large sites are |already using options like Hesiod to dynamically reconfigure resources. The |Hesiod support is simply added if the API would support res_mkquery(). [very good justification deleted] |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? Also, is this specific to operation with the DNS, or can use of res_mkquery() be transparently handled to a NIS server? My thoughts are that if an application needs functionality for arbitrary DNS calls, it should open a SOCK_DGRAM socket and go for their lives, with their own res_mkquery(). In this way applications that depend on having the DNS can do so, without the underlying stack being required to support other mechanisms such as NIS, or having the overhead imposed on them when such facilities are not required. Better still, maybe someone can create a DLL which includes just such 'extra' functions, which in turn uses Winsock to open a UDP port, then that DLL will only be loaded by the applications that need them. Better yet, if such library is made freely distributable, all the stack vendors don't have to duplicate the work in producing identically-operating versions - this _is_ what dynamic link libraries are all about, isn't it? Build it, and they will come. -- 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 MarkW@ms70.nuwes.sea06.navy.mil Tue Mar 15 23:32:00 1994 Received: from m65sun.nuwes.sea06.navy.mil by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15225; Wed, 16 Mar 1994 10:40:49 -0500 Received: from ms70.nuwes.sea06.navy.mil ([140.178.70.3]) by m65sun.nuwes.sea06.navy.mil with SMTP id AA15374 (5.65c/IDA-1.4.4 for winsock-hackers@sunsite.unc.edu); Wed, 16 Mar 1994 04:45:47 -0800 Received: by ms70.nuwes.sea06.navy.mil with Microsoft Mail id <2D87285A@ms70.nuwes.sea06.navy.mil>; Wed, 16 Mar 94 07:40:10 PST From: West Mark 5741 To: 'Winsock Hackers' Subject: FW: What's happening here? Date: Wed, 16 Mar 94 07:32:00 PST Message-Id: <2D87285A@ms70.nuwes.sea06.navy.mil> Encoding: 48 TEXT X-Mailer: Microsoft Mail V3.0 I have written code to link to a custom listener (server) port on a unix machine. The server I wrote works with a client that I wrote in Unix, but Winsock gives me a problem. Winsock dies during (after) a send, that is the Unix gets a connection and then gets notification of a send and then tells me (via telnet) that the Winsock peer closed the connection, simultaneously Windows gives me a runtime error of 202, I don't know what application is sending this error. Here is the output of watch in Peter Tattam's winsock.dll 1.0: WSAStartup(257,282F:560A) socket(2,1,0) connect(3,282F:55FA,16) state = syn_sent 97.6 1111->1026 seq 681E3001 ack 00000001 SYN ACK wind 8192 opt 02041000 state = established 97.6 1026->1111 seq 00000001 ack 00000001 ACK wind 4096 state = closed 97.6 1026->1111 seq 00000001 RST wind 0 socket 3 killed Task 1A57 did not call WSACleanup 97.7 1111->1026 seq 681E3002 ack AC3E0001 RST ACK wind 8192 opt 02041000 Unknown TCP - sending reset 97.7 23->1024 seq 62FCBA8C ack EA2D004C PSH ACK wind 8192 data 120 2A 2A 2A 20 61 63 63 65 70 74 65 64 20 2A 2A 2A 0D 0A 52 65 61 64 69 6E 67 20 73 74 72 65 61 6D 20 6D 65 73 73 61 67 65 3A 20 43 6F 6E 6E 65 63 74 69 6F 6E 20 72 65 73 65 74 20 62 79 20 70 65 65 72 0D 0A 0D 0A 20 43 6F 6D 6D 61 6E 64 20 30 0D 0A 20 43 6C 69 65 6E 74 20 27 27 0D 0A 20 44 61 74 61 20 27 27 2A 2A 2A 20 61 63 63 65 70 74 65 64 20 2A 2A 2A 0D 0A 97.7 23->1024 seq 62FCBB04 ack EA2D004C PSH ACK wind 8192 data 19 45 6E 64 69 6E 67 20 63 6F 6E 6E 65 63 74 69 6F 6E 0D 0A state = closed 97.7 1024->23 seq EA2D004C RST wind 0 97.7 1024->23 seq EA2D004C RST wind 0 97.7 23->1024 seq 62FCBB17 ack EA2D004C RST ACK wind 8192 opt 02041000 Help. - Mark West. From mmthomas@hpccoa.corp.hp.com Wed Mar 16 04:30:02 1994 Received: from hpccoa.corp.hp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05626; Wed, 16 Mar 1994 17:56:49 -0500 Received: by hpccoa.corp.hp.com (1.36.108.7/15.5+IOS 3.22) id AA29087; Wed, 16 Mar 1994 12:30:03 -0800 From: Markham Thomas Message-Id: <9403162030.AA29087@hpccoa.corp.hp.com> Subject: Unix to Winsock select() To: winsock-hackers@sunsite.unc.edu Date: Wed, 16 Mar 94 12:30:02 PST Mailer: Elm [revision: 70.30] 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. -- Markham Thomas From paul@atlas.dev.abccomp.oz.au Thu Mar 17 04:05:39 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA13023; Wed, 16 Mar 1994 21:42:01 -0500 Received: by usage.csd.unsw.OZ.AU id AA16675 (5.65c/IDA-1.4.4); Thu, 17 Mar 1994 08:53:11 +1000 Received: by atlas (4.1/1.35) id AA12172; Thu, 17 Mar 94 09:05:41 EST Message-Id: <9403162305.AA12172@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 17 Mar 1994 09:05:39 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: MarkW@ms70.nuwes.sea06.navy.mil, Multiple recipients of list Subject: Re: FW: What's happening here? Thus expounded West Mark 5741 on Mar 16,11:08am: /-------------------- | | |I have written code to link to a custom listener (server) port on a unix |machine. The server I wrote works with a client that I wrote in Unix, but |Winsock gives me a problem. Winsock dies during (after) a send, that is the |Unix gets a connection and then gets notification of a send and then tells |me (via telnet) that the Winsock peer closed the connection, simultaneously |Windows gives me a runtime error of 202, I don't know what application is |sending this error. | |Here is the output of watch in Peter Tattam's winsock.dll 1.0: | |WSAStartup(257,282F:560A) |socket(2,1,0) |connect(3,282F:55FA,16) |state = syn_sent | 97.6 1111->1026 seq 681E3001 ack 00000001 SYN ACK wind 8192 opt 02041000 |state = established | 97.6 1026->1111 seq 00000001 ack 00000001 ACK wind 4096 |state = closed | 97.6 1026->1111 seq 00000001 RST wind 0 |socket 3 killed 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. Another point, but which is unlikely to cause a problem, is that this shows Trumpet Winsock to start TCP connections with sequence number 1. RFC 1122 and RFC 793 both clearly state a clock-driven scheme must be used to select the Initial Sequence Number, so that delayed segments don't appear to be part of a subsequent connection. Both these points should be reported to your Winsock supplier, presumably Peter Tattam, along with the above trace. -- 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 tcemail!is3.indy.tce.com!FisherM@uunet.uu.net Thu Mar 17 09:14:00 1994 Received: from relay2.UU.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19690; Thu, 17 Mar 1994 18:59:44 -0500 Received: from uucp6.UU.NET by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhrg09779; Thu, 17 Mar 94 18:06:39 -0500 Received: from tcemail.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Thu, 17 Mar 1994 18:06:44 -0500 Reply-To: tcemail!FisherM@is3.indy.tce.com Received: from MSMAIL.INDY.TCE.COM (157.254.98.63) by nipper.indy.tce.com (PMDF #12222) id <01HA3593E89S8WZ9FK@nipper.indy.tce.com>; Thu, 17 Mar 1994 17:39 EST Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <2D890654@MSMAIL.INDY.TCE.COM>; Thu, 17 Mar 94 17:39:32 PST Date: Thu, 17 Mar 94 17:14:00 PST From: Fisher Mark Subject: RE: DNS interface To: WinSock-Hackers Message-Id: <2D890654@MSMAIL.INDY.TCE.COM> Encoding: 23 TEXT X-Mailer: Microsoft Mail V3.0 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... I do like the idea of a standard DLL for this. ====================================================================== Mark Fisher Thomson Consumer Electronics fisherm@tcemail.indy.tce.com Indianapolis, IN "Just as you should not underestimate the bandwidth of a station wagon traveling 65 mph filled with 8mm tapes, you should not overestimate the bandwidth of FTP by mail." From ICH211@ZAM001.ZAM.KFA-JUELICH.DE Fri Mar 18 13:21:15 1994 Received: from zam001.zam.kfa-juelich.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA18806; Fri, 18 Mar 1994 06:22:00 -0500 Message-Id: <199403181122.AA18806@SunSITE.Unc.EDU> Received: from DJUKFA11 by ZAM001.ZAM.KFA-JUELICH.DE (IBM VM SMTP V2R2) with BSMTP id 0501; Fri, 18 Mar 94 12:22:18 +0100 Date: Fri, 18 Mar 94 12:21:15 +0100 From: Thomas Heil Organization: Forschungszentrum Juelich GmbH - Institut fuer Chemie 2 Subject: Announcing Windows LPR Spooler 4.0 To: winsock@sunsite.unc.edu, winsock-hackers@sunsite.unc.edu, winsock-users@sunsite.unc.edu, FTP Software User's Group mailing list , TCP/IP Protocol Implementations for PC Discussion , Thomas Heil I would like to announce a new version of my LPR based printer spooler for Microsoft Windows. It has been restructered and got a few new features. The announcement text follows. Please note that I'm out of town until March 27. So if you mail me during this time my answer might be a bit delayed. /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 ======================================================================== WLPRSPL 4.0, a Windows Sockets based print spooler for transparent printing to LPD print servers from Windows Applications WLPRSPL 4.0 allows you to print transparently from any Windows application to network printers. All that is needed is a Protocol DLL that implements an API for sending print jobs to such a remote printer. Included is WLPR2.DLL which implements the LPD protocol (RFC1179) and allows printing to LPD print servers (typically some UNIX hosts). Requirements: o Microsoft Windows 3.1 o A Protocol DLL like the included WLPR2.DLL. o Networking software that offers a Windows Sockets 1.1 DLL if the included WLPR2.DLL is used as Protocol DLL (that's the normal case for printing to LPR/LPD (RFC 1179) based printers). Changes since release 4.0: o Now uses the Protocol DLL WLPR2.DLL which allows the use of several different Protocol DLLs for different remote printers side by side. WLPR2.DLL is a re-write of the old WLPR.DLL and is not compatible with the latter. o The program now has a so-called unattended mode which causes the program to automatically retry failed print job transfers after a user-definable amount of time. o Uses CTL3D.DLL from Microsoft to give dialogs a 3D look. Availability: The ZIP archive containing the packages is WLPRS40.ZIP. The software was uploaded to the following Anonymous FTP sites: o sunsite.unc.edu in /uploads Final destination directory: /pub/micro/pc-stuff/ms-windows/winsock/apps o ftp.cica.indiana.edu in /pub/pc/win3/uploads Final destination directory: /pub/pc/win3/util or /pub/pc/win3/winsock The ZIP file contains the program and necessary DLLs as well as documentation in form of an MS Word for Windows 2.0 file and a plain ASCII file. For installation and operating instructions please refer to this documentation. A PostScript version can be sent by E-mail on demand. The program is Shareware. From SVILLAMO%UTPVM1.BITNET@uga.cc.uga.edu Fri Mar 18 09:13:25 1994 Received: from uga.cc.uga.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA16844; Sat, 19 Mar 1994 14:12:41 -0500 Message-Id: <199403191912.AA16844@SunSITE.Unc.EDU> Received: from UTPVM1 by uga.cc.uga.edu (IBM VM SMTP V2R2) with BSMTP id 9861; Sat, 19 Mar 94 14:13:09 EST Received: from UTPVM1 (SVILLAMO) by UTPVM1 (Mailer R2.10 ptf000) with BSMTP id 6621; Sat, 19 Mar 94 14:14:42 EDT Date: Fri, 18 Mar 94 13:13:25 EDT From: Samuel Villamonte Subject: FORKNI-L signoff request To: "Rober_Allan...(?)" Hi, I read your message in the list digest and just to lend a hand: send a message to LISTSERV@psuvm.psu.edu (no subject required as far as I know) and in the body of the message put SIGNOFF FORKNI-L I don't know if the site is in capital letters or not, I'm in BITNET. And exactly why do you want to signoff? Is a great list, but I admit they send too much mail. Samuel From wilson@ftp.com Sat Mar 19 14:35:51 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA26703; Sat, 19 Mar 1994 19:36:07 -0500 Received: by ftp.com ; Sat, 19 Mar 1994 19:35:51 -0500 From: wilson@ftp.com (Brad Wilson) Message-Id: <9403200035.AA21178@ftp.com> Subject: Re: Unix to Winsock select() To: mmthomas@hpccoa.corp.hp.com Date: Sat, 19 Mar 1994 19:35:51 -0500 (EST) Cc: winsock-hackers@sunsite.unc.edu In-Reply-To: <9403162030.AA29087@hpccoa.corp.hp.com> from "Markham Thomas" at Mar 19, 94 06:39:54 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 885 >> 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. Unfortunately, since Windows is not Unix and sockets are not tied at a low level to the file system, there is no guarantee that the numbers you will get will even be inside a bitmask. There is no written rule that socket IDs must start with an arbitrarily low number and be incremented by one. The macros for FD_SET, FD_CLEAR and FD_ISSET are compatible with the BSD system. These should be used if you're interested in writing a complete portable program. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet Email: wilson@ftp.com "The facts, although interesting, are irrelevant." From patrick@nerdvana.mv.com Mon Mar 21 08:23:32 1994 Received: from mv.MV.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA22118; Mon, 21 Mar 1994 13:38:43 -0500 Received: by mv.mv.com (8.6.8/mem-931109) id NAA28482; Mon, 21 Mar 1994 13:35:32 -0500 Received: by nerdvana (4.1/SMI-4.1) id AA08846; Mon, 21 Mar 94 13:23:32 EST Date: Mon, 21 Mar 94 13:23:32 EST From: patrick@nerdvana.mv.com (Patrick Murphy) Message-Id: <9403211823.AA08846@nerdvana> To: mmthomas@hpccoa.corp.hp.com Cc: winsock-hackers@SunSITE.Unc.EDU In-Reply-To: <9403162030.AA29087@hpccoa.corp.hp.com> (message from Markham Thomas on Sat, 19 Mar 1994 06:39:54 -0500) Subject: Re: Unix to Winsock select() > 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. > > -- Markham Thomas I too have encounter this, in my case it was winsock BSD code ported to the HP9000. The way I dealt with it was to create a typedef for a fd_set pointer, and contionally define it based on the OS. ie #if defined hpux #define FDSETPTR int * #else #define FDSETPTR fd_set FAR * #endif IMHO In this case winsock is correct. HP for some reason only known to them declares the fd_set * arguments to select as int *. Stick with fd_set FD_ZERO, FD_ISSET, etc and you should remain portable. Pat ====================================================================== Patrick Murphy patrick@nerdvana.mv.com see also: patrick@keyfile.com CI$ 72570,1560 ====================================================================== From natale@acec.com Mon Mar 21 19:50:32 1994 Received: from uu6.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA08669; Tue, 22 Mar 1994 01:00:18 -0500 Received: from acec.com by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00852 for winsock-hackers@sunsite.unc.edu; Tue, 22 Mar 94 00:53:14 -0500 Date: Tue, 22 Mar 1994 00:50:32 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA25109; Tue, 22 Mar 1994 00:50:32 -0500 Message-Id: <9403220550.AA25109@nips.acec.com> To: pete@tecc.co.uk Subject: Re: WSAAsynchSelect(), FD_WRITE etc Cc: winsock-hackers@sunsite.unc.edu, winsock@sunsite.unc.edu > Date: Mon, 21 Mar 1994 20:27:05 -0500 > From: pete@tecc.co.uk (Pete Bentley) Hi Peter, I apologize in advance for only attempting to answer a few of your questions...as you will see below, I am forwarding your message (by copy hereof) to the winsock-hackers list, and I expect that those (multitudes) more knowledgeable than me will post some answers too. > [Er, if there is a newsgroup / mailing list where winsock programmers > hang out, I'd be grateful if someone would point me at it. It's hard > to keep up with alt.winsock as 99% of it is noise (from a programmer's > point of view :-)] Subscribe to winsock-hackers@sunsite.unc.edu, by sending e-mail: To: listserv@sunsite.unc.edu Subject: subscribe winsock-hackers Pete Bentley (Actually, I've meaning to run a check to see how many folks are on "winsock-hackers" but not "winsock". It's kinda hard to get a sustained discussion going on winsock-hackers. Hence the otherwise unfortunate cross-posting of this reply back to the main "winsock" list.) :-( > According to my version of the Winsock 1.1 spec, when WSAAsyncSelect() > is called with FD_WRITE set in the event mask, This was the topic of a recent series of exchanges on winsock-hackers, and the solid consensus was that if the socket is writable at the/any time that a WSAAsyncSelect() (with FD_WRITE set) is called, then an FD_WRITE message should be posted by the DLL. > no message is returned to the application until some send() call > actually blocks. Fair enough. Actually, bearing in mind my previous answer, in the case you cite immediately above, you should not get an FD_WRITE messge after a WSAEWOULDBLOCK error _until_ sufficient DLL buffer space is again available. > Some DLLs seem to try and be 'helpful' including the free Microsoft > stack and Trumpet (up to alpha #18, at least) and will deliver an > FD_WRITE indication if a WSAAsyncSelect() is issued on a socket which > includes FD_WRITE *if* the previous mask didn't include FD_WRITE *and* > the socket is currently writable. I don't think the "*if*" part is correct; the "*and*" part is. There appears to be some possible degree of ambiguity wrt the term "initially" on pp. 90-91 of the v1.1 spec wrt FD_WRITE postings. > In my opinion, this behavious is more useful, as it will naturally > kick-start applications which are totally message driven. As they should be. :-) And you really should try to avoid using superfluous WSAAsyncSelect() calls to [re]set notification requests (which typically only need to be set once per socket per . > As it happens I have written a set of class libraries which are > totally event driven and do their 'real' work by making callbacks to > the application code (it overrides member functions). One application > which makes use of these classes is basically structured as a state > machine, with certain state transitions being made when all the data > that the application queued on a socket has made it through send() > (this app is making use of buffering within the socket class so it > issue lots of small send()'s without causing network load (or having > to rely on Nagel algorithms within the Winsock DLL to do that)). > > Now, my previous strategy was to add FD_WRITE to an internal event > mask and issue a new WSAAsyncSelect() whenever data was added to an > empty buffered socket, Sounds like this last step ("...issue a new WSAAsyncSelect()...) is something you should avoid. We have observed problems in our code when taking this approach...and regardless of who was to blame, going to a more Spartan approach to using WSAAsyncSelect() both removed the problem and "simplified" our code vis-a-vis the Windows programming model. > then when the app returns to Windows, many (most?) > Winsock DLLs will send a message indicating FD_WRITE and the data gets > sent to send(). Yes, if the writable state exists when WSAAsyncSelect() is called with FD_WRITE, then the DLL _should_ post the FD_WRITE message. (But bear in mind my earlier comments about the ambiguity of the term "initially" in the spec.) > And then someone tries to use the application with FTP's PC/TCP stack > & DLL and it falls flat because this DLL really won't deliver an > FD_WRITE indication until a send() returns EWOULDBLOCK. I know that Bob Quinn of FTP has posted very knowledgeable messages on winsock-hackers about the proper flow of FD_WRITE, so I am sure that he will be able to help you here...maybe it's a version thing ...that's a pretty common problem across the board today. > Reading the spec closely, I can't fault them for that, but its a > real pain. I'd be interested in hearing how you interpret the description of the FD_WRITE message flow on pp. 90-91 or so of the v1.1 spec.... I think I'll skip the next two paragraphs...this is getting ugly! ;-) > Suddenly code which was happily event driven needs to be kick started > by a flush() function if there is a chance the socket isn't blocked. > And to make the class libraries work I either have to call the > callbacks directly or post fake FD_WRITE messages. Neither of these > approaches are desirable, one risks recursion (the callback is > extremely likely to queue more data which may need to be flush()ed) > and the other tends to overlflow the task's message queue when run > with a 'nice' DLL which is also queuing FD_WRITE indications. > > Anyway, looking at it (hopefully) objectively, the approach where the > DLL sends extra FD_WRITE messages is cleaner from an event-driven > point of view, and is no extra stress on applications written for the > behavious in the 1.1 spec, as they have to cope with spurious FD_WRITE > messages anyway. So my questions are:- > > 1) Any chance of this being changed in a future winsock spec. ie > mandate that if an application does a WSAAsyncSelect() including > FD_WRITE and the socket is writable that one FD_WRITE indication gets > sent immediately. Well, except for some ambivalence wrt "immediately", my understanding is that what you suggest is what is supposed to be happening now (i.e., with the v1.1 spec). > 2) How do other people using the async. interface cope with this if > they want to keep the socket code as seperate as possible from the > application code. We've had to work at. But removing superfluous WSAAsyncSelect() calls seemed to help our code (I don't do it first-hand...just try to follow the problem resolution cycles). > 3) What does a return value of 0 from send() mean? Neither the > winsock spec. nor any of the Unix manuals I have to hand say this > means anything special (like EOF when recv() returns 0). I only ask > because the Microsoft DLL seems to often send an FD_WRITE message to > the application, but when the application tries a send() it returns 0. > As my socket classes use a pretty standard loop write (loop until all > data written or send() returns SOCKET_ERROR), this just means they > sometimes loop rapidly through about 60 send() calls, all returning 0 > until the DLL finally accepts some data. Curious, eh? I certainly > can't afford to treat this the same as -1/EWOULDBLOCK because I very > much doubt I would get another FD_WRITE...Just another Microsoft bug, > I guess. Like Bob Quinn for FTP, J. Allard and/or David Treadwell often posts concise, precise answers to such WinSock programming questions for Microsoft...so I hope (and trust) that one of them (or one of their associates) will post an answer for you. Good luck, 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 jackm@suneast.east.sun.com Wed Mar 16 00:04:11 1994 Received: from Sun.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA15159; Tue, 22 Mar 1994 05:06:25 -0500 Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB09154; Tue, 15 Mar 94 16:06:25 PST Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1) id AA01808; Tue, 15 Mar 94 19:06:06 EST Received: from roxanne.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1) id AA24860; Tue, 15 Mar 94 19:06:22 EST Received: by roxanne.East.Sun.COM (5.0/SMI-SVR4) id AA05572; Tue, 15 Mar 1994 19:04:11 +0500 Date: Tue, 15 Mar 1994 19:04:11 +0500 From: jackm@suneast.east.sun.com (Jack Morrison - Sun BOS Product Assurance) Message-Id: <9403160004.AA05572@roxanne.East.Sun.COM> To: winsock-hackers@sunsite.unc.edu Subject: unsubscribe X-Sun-Charset: US-ASCII Content-Length: 0 From rcq@mailserv-D.ftp.com Tue Mar 22 07:41:43 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA17510; Tue, 22 Mar 1994 12:42:33 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 22 Mar 1994 12:42:32 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA16314; Tue, 22 Mar 94 12:41:43 EST Date: Tue, 22 Mar 94 12:41:43 EST Message-Id: <9403221741.AA16314@mailserv-D.ftp.com> To: pete@tecc.co.uk, natale@acec.com Subject: Re: WSAAsynchSelect(), FD_WRITE etc 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 Tue Mar 22 12:41:32 1994] Originating-Client: oysters.ftp.com Content-Length: 4587 > From: natale@acec.com (Bob Natale) > > > From: pete@tecc.co.uk (Pete Bentley) > > > > And then someone tries to use the application with FTP's PC/TCP stack > > & DLL and it falls flat because this DLL really won't deliver an > > FD_WRITE indication until a send() returns EWOULDBLOCK. > > I know that Bob Quinn of FTP has posted very knowledgeable messages > on winsock-hackers about the proper flow of FD_WRITE, so I am sure > that he will be able to help you here...maybe it's a version thing > ..that's a pretty common problem across the board today. Hmmm. My guess is you're using an older version of our WinSock.DLL, Pete. Please check the version number in the "Description field" as displayed by Microsoft's EXEHDR.EXE or Borland's TDUMP.EXE. Since the DLL version is kept in a string, you can look at it with anything that views strings in a binary. You can get the latest production version (v1.10) from our anonymous ftp server ftp.ftp.com:/support/winsock/winsock.exe (a self- extracting ZIP file), or the latest beta version from the beta directory below that /support/winsock/beta/wsbeta.exe (also a self-extracting ZIP). Our WinSock.DLL will issue an FD_WRITE initially after you call WSAAsynchSelect() if you request it (we will NOT send an FD_WRITE if you don't request FD_WRITE notification, as you've described some others will). With a UDP socket, it will notify you immediately if you are using a Datagram socket. With a TCP socket, it will notify you immediately if you are connected ...or upon connection completion (by connect() or accept()). > > Anyway, looking at it (hopefully) objectively, the approach where the > > DLL sends extra FD_WRITE messages is cleaner from an event-driven > > point of view, and is no extra stress on applications written for the > > behavious in the 1.1 spec, as they have to cope with spurious FD_WRITE > > messages anyway. So my questions are:- > > > > 1) Any chance of this being changed in a future winsock spec. ie > > mandate that if an application does a WSAAsyncSelect() including > > FD_WRITE and the socket is writable that one FD_WRITE indication gets > > sent immediately. > > Well, except for some ambivalence wrt "immediately", my understanding > is that what you suggest is what is supposed to be happening now (i.e., > with the v1.1 spec). I agree, the spec already says it. > > 3) What does a return value of 0 from send() mean? Neither the > > winsock spec. nor any of the Unix manuals I have to hand say this > > means anything special (like EOF when recv() returns 0). I only ask Gee, that's a good question! For return values, the spec says "if no error occurs, send() returns the total number of characters sent (note that this may be less than the number indicated by len). Otherwise, a value of SOCKET_ERROR is returned..." Hmm. Extrapolating from this, a WinSock provider can justify returning 0 since (I presume) it's less than the number requested, and of course they can send 0 successfully (like, I'm incredibly successful at making 0 millions of dollars :) That's not a nice thing for them to do though. They really should be returning a WSAEWOULDBLOCK in this case, especially since then you could count on the FD_WRITE message to pick up where you left off automatically. For now, you can loop around a return of 0 for a while, as you're doing ...but beware of an endless loop there (what happens if you unplug the network connection?). You might also consider using a timer to try again later as another or additional strategy. To be honest, this problem is similar to one with our WinSock DLL where send() can fail with WSAENOBUFS error. As Alun Jones made clear to me, this burdens an application with a similar problem. I have fixed this so we always return a WSAEWOULDBLOCK rather than WSAENOBUFS (although that version of our DLL is still in the QA cycle on it's way to becoming publicly available). Our original thinking was that the finer resolu- tion in the error code would help point out a potential configuration problem; now I know it does more to disservice than service. Getting back to send() returning 0, to make it inescapably clear, I'd say send() needs some new (explicit) language like "if no error occurs, send() returns the total number of characters sent (greater than 0)." ^^^^^^^ ^^^^^^^ Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From xtree!polyslo!central.com!dalec@polyslo.csc.calpoly.edu Tue Mar 22 07:49:00 1994 Received: from polyslo.csc.calpoly.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25637; Tue, 22 Mar 1994 19:24:00 -0500 Received: by polyslo.csc.calpoly.edu (5.61/2.890629) id AA07991; Tue, 22 Mar 94 16:23:57 -0800 Received: by xtree.xtree.com (/\==/\ Smail3.1.25.1 #25.19) id ; Sun, 6 Oct 35 23:20 PST Received: from hqcpsun.central.com by polyslo.csc.calpoly.edu (5.61/2.890629) id AA07355; Tue, 22 Mar 94 15:49:24 -0800 Received: from smtpgate.central.com by central.com (4.1/3.1.012693-Central Point Software); id AA02088 for xtree!polyslo!SunSITE.Unc.EDU!winsock-hackers@polyslo.csc.calpoly.edu; Tue, 22 Mar 94 15:47:25 PST Received: by smtpgate.central.com with Microsoft Mail id <2D8F841D@smtpgate.central.com>; Tue, 22 Mar 94 15:49:49 PST From: Dale Cabell To: winsock-hackers Subject: unsubscribe me please Date: Tue, 22 Mar 94 15:49:00 PST Message-Id: <2D8F841D@smtpgate.central.com> Encoding: 18 TEXT X-Mailer: Microsoft Mail V3.0 Now that XTree is part of Central Point Software please remove this address from this list. Thanks, DCabell@XTree.XTree.com (Last time) ---------- >From: winsock-hackers To: Multiple recipients of list Subject: unsubscribe Date: Tuesday, March 15, 1994 8:52AM From paul@atlas.dev.abccomp.oz.au Wed Mar 23 09:42:14 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA05894; Tue, 22 Mar 1994 23:31:30 -0500 Received: by usage.csd.unsw.OZ.AU id AA04461 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 23 Mar 1994 14:29:31 +1000 Received: by atlas (4.1/1.35) id AA29491; Wed, 23 Mar 94 14:42:14 EST Message-Id: <9403230442.AA29491@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 23 Mar 1994 14:42:14 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: natale@acec.com, pete@tecc.co.uk, Multiple recipients of list Subject: Re: WSAAsynchSelect(), FD_WRITE etc Thus expounded Bob Natale on Mar 22, 3:30am: /-------------------- |> Date: Mon, 21 Mar 1994 20:27:05 -0500 |> From: pete@tecc.co.uk (Pete Bentley) | |Hi Peter, | |I apologize in advance for only attempting to answer a few of your |questions...as you will see below, I am forwarding your message |(by copy hereof) to the winsock-hackers list, and I expect that |those (multitudes) more knowledgeable than me will post some answers |too. Bob, your answers to Peter's queries were perfectly correct. 1) When calling WSAAsyncSelect(), if any of the specified conditions are true at the time of the call (including write buffer space being available for FD_WRITE) the DLL _should_ post the appropriate message at the time of the call, so FD_WRITE _should_ be posted as soon as WSAAsyncSelect() is called. 2) Microsoft's habit of returning 0 if it could not write any data instead of SOCKET_ERROR/WSAEWOULDBLOCK is also against the explicit wording of the spec: The third paargraph in the 'Remarks' section of SEND() on page 48 says '...On non-blocking SOCK_STREAM sockets, the number of bytes written may be between 1 and the requested length...". Note, the lowest number allowed is '1', not '0'. You should take both these points up with FTP and Microsoft respectively - they may have upgraded their DLLs since, and you may not have the latest revision. Comments from the groups concerned ? -- 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 pete@tecc.co.uk Wed Mar 23 17:13:29 1994 Received: from luggage.tecc.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA14368; Wed, 23 Mar 1994 12:17:12 -0500 Received: from luggage.tecc.co.uk by luggage.tecc.co.uk id aa25199; 23 Mar 94 17:13 GMT To: winsock-hackers@sunsite.unc.edu Subject: Re: WSAAsynchSelect(), FD_WRITE etc Date: Wed, 23 Mar 1994 17:13:29 +0000 From: Pete Bentley Message-Id: <9403231713.aa25199@luggage.tecc.co.uk> In message <9403221741.AA16314@mailserv-D.ftp.com>, Bob Quinn writes: >> >> > From: natale@acec.com (Bob Natale) >> > >> > > From: pete@tecc.co.uk (Pete Bentley) >> > > >> > > And then someone tries to use the application with FTP's PC/TCP stack >> > > & DLL and it falls flat because this DLL really won't deliver an >> > > FD_WRITE indication until a send() returns EWOULDBLOCK. >> > >> > I know that Bob Quinn of FTP has posted very knowledgeable messages >> > on winsock-hackers about the proper flow of FD_WRITE, so I am sure >> > that he will be able to help you here...maybe it's a version thing >> > ..that's a pretty common problem across the board today. >> >> Hmmm. My guess is you're using an older version of our WinSock.DLL, Pete. >> Please check the version number [...] Thanks for that info, but it is somewhat out of my control --- the application is free software (winflex, a Windows client for flexfax), and I was responding to a problem report from a user. Naturally I want the program to work with as many winsock DLLs as possible so that it is useful, so when this user sent me a log showing a transmission timeout (because of the non-arrival of an initial FD_WRITE indication) I re-read my version of the spec (version 1.1, 20Jan93) which says FD_WRITE is only delivered on connect(), accept() or after a send() has failed, so I decided I'd better change the code... >> >> Our WinSock.DLL will issue an FD_WRITE initially after you call >> WSAAsynchSelect() if you request it (we will NOT send an FD_WRITE if >> you don't request FD_WRITE notification, as you've described some >> others will). Um, no. I never meant to suggest that --- maybe I expressed it badly. What I meant to say was that some DLLs post an FD_WRITE when I do a WSAAsynchSelect() with write set and the socket is writable even if no send() has blocked. Anyway, my understanding of the situation is as follows (sorry to post it to the list, but I got some conflicting, privately Emailed answers and so I wanted to see what the list said). i) If a socket is not currently selecting on FD_WRITE and issues a new WSAAsynchSelect() with FD_WRITE set, then the WinSock DLL should post an FD_WRITE message immediately (well, very soon) if the socket is writable. DLLs which do not exhibit this behaviour can be considered 'broken'. ii) It is generally considered that an application should not change its select mask with WSAAsynchSelect() too often (I had noticed that this tends to kill some versions of the LWP DLL in the past). I have to admit that I don't like (ii). It makes it harder to divorce comms code from the application. Consider winflex, which has to speak flexfax' application protocol which is quite complex and involves user authorisation, submission of (lots of) PostScript fax data, then submission of a list of destinations and cover sheets (which is more PostScript, but generated on the fly). To make this protocol event driven, it is coded as a state machine where each state's handler is capable of resuming transmission when it can write more data. Each state handler is called (basically) when all the data it wrote to a tcSocket (C++ object) was been written to the WinSock socket via send(). Some state handlers generate their data in small chunks (eg lines of PostScript) and so I actually use a tcBufferedSocket which adds stdio type functionality to a tcSocket (because we need to read data back line by line, too). Anyway, I'm digressing, the point is that the application can be coded quite simply within the spec if the tcBufferedSocket is allowed to toggle the FD_WRITE bit in its select mask --- It simply sets FD_WRITE when it has data queued to send, then when the application returns to Windows an FD_WRITE will occur at some time and some data gets passed to send(). If all the data has been sent, FD_WRITE is cleared and a callback called so the application can queue more data or change states or whatever. So, the application can be quite naive, the only comms knowledge it needs is that it can queue as much (or little) data is it desires up to the size of the tcSocket buffer, then return to Windows knowing it will get called back when the tcSocket's buffer is empty again. The tcSocket doesn't need to worry about keeping track of the socket state, all it needs to know is that if it adds FD_WRITE to the socket's select mask then messages will start arriving to drive the transmission process, and that it must clear the FD_WRITE mask when it has sent the data to ensure it will messages later. All nice, neat, OO, event driven [insert your favourite buzzwords here], but it does require calling WSAAsynchSelect() with different masks regularly. The same functionality could be got by using a single WSAASynchSelect() at connect() time and then getting the tcBufferedSocket::send() member to post a fake FD_WRITE to kick-start itself if it knows there isn't already one outstanding. Doesn't seem correct, though, somehow. >> > > 3) What does a return value of 0 from send() mean? Neither the >> > > winsock spec. nor any of the Unix manuals I have to hand say this >> > > means anything special (like EOF when recv() returns 0). I only ask >> >> [...] >> They really should be returning a WSAEWOULDBLOCK in this case, especially >> since then you could count on the FD_WRITE message to pick up where you >> left off automatically. For now, you can loop around a return of 0 for >> a while, as you're doing ...but beware of an endless loop there (what >> happens if you unplug the network connection?). You might also consider >> using a timer to try again later as another or additional strategy. >> >> Getting back to send() returning 0, to make it inescapably clear, >> I'd say send() needs some new (explicit) language like "if no error >> occurs, send() returns the total number of characters sent (greater >> than 0)." ^^^^^^^ >> ^^^^^^^ >> Hmm, I don't mind send() returning 0 providing the implementors notes specifically say this must be a very temporary situation and put the obligation on the DLL to either return a positive number or SOCKET_ERROR within a few loops --- It might save a few pointless turns around the system message loop. Having said that, if the innards of the DLL know enough to guarentee actually sending data in the very near future, then they might as well just sit in a loop inside the DLL for those few milliseconds... Pete. From bryan%alex.com@gateway.alex.com Wed Mar 23 18:34:22 1994 Received: from post.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11237; Wed, 23 Mar 1994 19:17:55 -0500 Received: by post.demon.co.uk id ab12911; 23 Mar 94 19:34 GMT Received: from gateway.alex.com by post.demon.co.uk id aa06735; 23 Mar 94 18:45 GMT Return-Path: Received: from SKID by woody.alex.com (4.1/SMI-4.1) id AA12912; Wed, 23 Mar 94 18:34:22 GMT Date: Wed, 23 Mar 94 18:34:22 GMT Message-Id: <9403231834.AA12912@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: Closing and reusing sockets X-Mailer: I have observed some interesting behaviour on exiting an application and re-entering, and so I post to the net looking for advice or sympathy. The following was observed with PC/TCP 2.2 and winsock.dll v1.10. The application opens three sockets, does some sending and receiving, then closes them, calls WSACleanup, and exits. 1) The second closesocket() failed with WSAEINPROGRESS. This problem went away when I removed an odd call to setsockopt(SO_LINGER); it was passing an int of zero rather than a struct with the first int == 0. Nontheless, I would think that WSAEINPROGRESS should only result from a re-entrant message dispatch coming from a genuinely blocking call -- in this case the first closesocket() had just returned, with no error. 2) On restarting the application very quickly after it has just exited, the second socket will fail to connect() with WSAADDRINUSE. This is odd, because bind() on that socket has just succeeded. This problem can be made to disappear by setting SO_LINGER to {1,0} before closing the socket, i.e. forcing a hard close. So it looks as if the socket was lingering for a little while, so why didn't bind() tell me that the address was in use so I could pick a different one? Thanks in advance for any help, Bryan Boreham Alex Technologies Ltd. From pete@tecc.co.uk Thu Mar 24 21:19:12 1994 Received: from luggage.tecc.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA10850; Thu, 24 Mar 1994 16:20:51 -0500 Received: from luggage.tecc.co.uk by luggage.tecc.co.uk id aa04837; 24 Mar 94 21:19 GMT To: winsock-hackers@sunsite.unc.edu Subject: getXbyY() Date: Thu, 24 Mar 1994 21:19:12 +0000 From: Pete Bentley Message-Id: <9403242119.aa04837@luggage.tecc.co.uk> I know it's bad form, but for simplicity in my otherwise async. socket classes I use the blocking getXbyY() calls --- to me this is acceptable as my applications are LAN based and so likely to be resolviong local names via a local nameserver. As time allows I will recode the socket classes to do The Right Thing with the WSAGetXbyY() calls... Anyway, I got another report of my application not working with PC/TCP (v1.10) again today. (I don't have a downer on FTP software, I just seem to have problems with their DLL sometimes). If you recall my previous PC/TCP problem with FD_WRITE messages, I recoded it all to use a single WSAAsynchSelect() and post fake FD_WRITEs as appropriate and the result works on several DLLs (PC/TCP 1.06 & 1.10, Microsoft etc). Anyway, the chap testing winflex got more adventurous and set it up as a fake Windows PostScript printer and found it suddenly failed to resolve hostnames when submitting a fax which was printed, but could handle fax submission invoked from the menu. As far as the code is concerned the only difference is the event handler which creates the socket and starts the connection (after that everything goes asynch. in both cases). In the menu invoked case everything is in response to a normal WM_COMMAND message. In the 'printed file' case, the application is responding to a WM_SPOOLERSTATUS message posted by the Print Manager to all applications. The socket classes log all winsock calls, and the successful (WM_COMMAND) case includes the following:- Information: Connecting to 'teal' Trace: tcSocket(087F:8F44)::Connect(teal, fax, tcp) Debug: tcSocket(087F:8F44): getservbyname(fax, tcp) Trace: tcSocket(087F:8F44)::Connect(teal, 4557) Debug: tcSocket(087F:8F44): gethostbyname(teal) Debug: IP Address = 149.121.128.88 And the unsuccessful case includes:- Information: Connecting to 'teal' Trace: tcSocket(087F:84D4)::Connect(teal, fax, tcp) Debug: tcSocket(087F:84D4): getservbyname(fax, tcp) Trace: tcSocket(087F:84D4)::Connect(teal, 4557) Debug: tcSocket(087F:84D4): gethostbyname(teal) ERROR: Host name lookup failure for "teal": WSANO_DATA: No host data record of requested type Now these people are using DNS, so the blocking gethostbyname() has to handle some UDP comms itself. However, I don't see why a) Being invoked via the WM_SPOOLERSTATUS handler is any differemt or b) Why WSANO_DATA gets returned. Why not WSANO_RECOVERY or similar? Short of biting the bullet and recoding using the (correct) aynch. functions, what can I do? Pete. PS I am not 100% sure I am properly subscribed to the list, so could someone post me a message confirming this made it to the list, please? From natale@acec.com Fri Mar 25 05:49:40 1994 Received: from uu3.psi.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA24113; Fri, 25 Mar 1994 10:53:31 -0500 Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA07969 for winsock-hackers@sunsite.unc.edu; Fri, 25 Mar 94 10:53:06 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13902; Fri, 25 Mar 1994 10:52:16 -0500 Date: Fri, 25 Mar 1994 10:49:40 EST From: Bob Natale Subject: Re: WSAAsynchSelect(), FD_WRITE etc To: pete@tecc.co.uk Cc: Multiple recipients of list Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Pete Bentley > Date: Fri, 25 Mar 1994 07:25:54 -0500 Hi Pete, > >> Our WinSock.DLL will issue an FD_WRITE initially after you call > >> WSAAsynchSelect() if you request it (we will NOT send an FD_WRITE if > >> you don't request FD_WRITE notification, as you've described some > >> others will). > Um, no. I never meant to suggest that --- maybe I expressed it badly. > What I meant to say was that some DLLs post an FD_WRITE when I do a > WSAAsynchSelect() with write set and the socket is writable even if no > send() has blocked. This is correct behavior, per the spec (given some ambiguity wrt the term 'initially'.) > Anyway, my understanding of the situation is as follows (sorry to post > it to the list, but I got some conflicting, privately Emailed answers > and so I wanted to see what the list said). Very good of you. I too am intensely interested in making sure that we all have a correct, common understanding...or that I get my own mistakes corrected! > i) If a socket is not currently selecting on FD_WRITE and issues a new > WSAAsynchSelect() with FD_WRITE set, then the WinSock DLL should post > an FD_WRITE message immediately (well, very soon) if the socket is > writable. DLLs which do not exhibit this behaviour can be considered > 'broken'. Correct on both counts. > ii) It is generally considered that an application should not change > its select mask with WSAAsynchSelect() too often (I had noticed that > this tends to kill some versions of the LWP DLL in the past). This _seems_ to be a practical fact. > I have to admit that I don't like (ii). I don't either...but not for your reasons. I don't like it because the spec does not imply any adverse side-effects to calling WSAAsyncSelect() multiple times. > It makes it harder to divorce comms code from the application. [lots of interesting explanation deleted] There are almost always multiple viable alternative software designs. Often, only the total system effect can weed out the 'better' from the 'less good' (we've already discounted the 'bad'). The one you described in the deleted portion is obviously viable, and might be among the 'better' given a certain desired overall system effect. However (in the absence of more detailed knowledge about that desired overall system effect), I have to say that I would choose a different strategy than the one you described... > The same functionality could be got by using a single > WSAASynchSelect() at connect() time And, almost always, this is the approach I would recommend... given the right assumptions (I'm too wordy as it is :-), you will receive an FD_WRITE message automatically as a result of this. > and then getting the tcBufferedSocket::send() member to post > a fake FD_WRITE to kick-start itself if it knows there isn't > already one outstanding. Not necessary; not recommended. FD_WRITE is a signal from the DLL about the state of the DLL/transport interface. It's not a signal about the state of the application. > Doesn't seem correct, though, somehow. It's not, IMHO, for the reason I just stated. Your app should keep track of "Do I have anything to write" at one level (let's call this 'A') and "Is WinSock ready for me to write" at another level ('B') and actually writing something at another level ('C'). Now, 'C' depends on 'A', which depends on 'B'. 'B' does not depend on 'A'; but might be impacted by 'C'. After posting a single WSAAsyncSelect() message (on a socket, and asking for FD_WRITE notification), then -- assuming correct operation of the DLL -- your app should just let 'B' take care of itself...and not doing 'C' unless 'A' && 'B'. I apologize for being repetitive, redundant, superfluous, vague, and/or pedantic (the latter is definitely not intentional)...I'm just trying to make sure I've got a solid handle on this and there is no better forum to expose the flaws in my thinking than this one. "C'mon, hit me with your best shot!" (Bonnie Raitt) Thanks, BobN ________________________________________________________________ Bob Natale | American Computer | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com From rcq@mailserv-D.ftp.com Fri Mar 25 05:59:11 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25206; Fri, 25 Mar 1994 10:59:54 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 25 Mar 1994 10:59:54 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24262; Fri, 25 Mar 94 10:59:11 EST Date: Fri, 25 Mar 94 10:59:11 EST Message-Id: <9403251559.AA24262@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 Fri Mar 25 10:59:07 1994] Originating-Client: oysters.ftp.com Content-Length: 866 Hello Bryan! > I have observed some interesting behaviour on exiting an application > and re-entering, and so I post to the net looking for advice or sympathy. > The following was observed with PC/TCP 2.2 and winsock.dll v1.10. My guess is you got this DLL version number from our WINET utility, which shows the version of the WinSock spec supported, not the version of the DLL itself (believe me, I wish it didn't do this). You should ftp to ftp.ftp.com and get /support/winsock/winsock.exe (a self-extracting ZIP file with the latest shipping WinSock.DLL) and/or get our beta version from /support/winsock/beta/wsbeta.exe (also a self-extracting ZIP file). > Bryan Boreham > Alex Technologies Ltd. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Fri Mar 25 05:59:10 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25204; Fri, 25 Mar 1994 10:59:53 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 25 Mar 1994 10:59:53 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24260; Fri, 25 Mar 94 10:59:10 EST Date: Fri, 25 Mar 94 10:59:10 EST Message-Id: <9403251559.AA24260@mailserv-D.ftp.com> To: pete@tecc.co.uk Subject: Re: WSAAsynchSelect(), FD_WRITE etc 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 Fri Mar 25 10:59:07 1994] Originating-Client: oysters.ftp.com Content-Length: 4079 Hi Pete! > i) If a socket is not currently selecting on FD_WRITE and issues a new > WSAAsynchSelect() with FD_WRITE set, then the WinSock DLL should post > an FD_WRITE message immediately (well, very soon) if the socket is > writable. DLLs which do not exhibit this behaviour can be considered > 'broken'. Let's be specific. Sockets come in two types: DGRAM & STREAM. We're concentrating on STREAM here (FD_WRITE on DGRAM is not too meaningful anyway). When you call WSAAsyncSelect(), you can have two different socket states: Connnected & Not Connected. The spec says WinSock posts an FD_WRITE "when a socket is first connected with connect() or accepted with accept()." This is very clear. If you get a socket, call WSAAsyncSelect with FD_WRITE, then call either function *which succeeds*, the DLL should send an FD_WRITE message. No argument there, right? The spec also says "If an event is true when the application initially calls WSAAsyncSelect(), or when a reenabling function is called, then a message is posted as appropriate." Appropriate here should be considered a state of being connected, because you cannot send() on a non-connected STREAM socket. Hence, if you are currently connected when you call WSAAsyncSelect with FD_WRITE, you can expect to get an FD_WRITE message. Conversely, if you are not connected yet, you should NOT expect an FD_WRITE message. Let's look at a pathological case: - get a socket - make it non-blocking (with ioctlsocket()). - call connect() ...which returns WSAEWOULDBLOCK --- you're connection is pending --- - call WSAAsyncSelect with FD_WRITE set If you're connection is still pending while the WSAAsyncSelect() call is processed, should it post an FD_WRITE??? Within the spirit of the how FD_WRITE is supposed to work, the answer is NO since the socket is not writable. However, it is not a violation for the WinSock to do so. They can legally send an FD_WRITE because although it means "send() can be issued with the expectation of immediate success. Nevertheless, a robust application must be prepared for the possibility that it may receive a message and issue a Windows Sockets API call which returns WSAEWOULDBLOCK immediately." Ideally though, the WinSock should defer the FD_WRITE notification until the connection has completed or failed (in which case it would send the error code along with the notification message). That is the way it's designed to be used. > ii) It is generally considered that an application should not change > its select mask with WSAAsynchSelect() too often (I had noticed that > this tends to kill some versions of the LWP DLL in the past). This is very implementation dependent. The bottom line is you should be able to call WSAAsyncSelect() as many times as you want to. But it's not recommended. You may end up with a very confused application if it doesn't know how to handle the extra notification messages extra calls to the WSAAsyncSelect() function will generate. It is not necessary to call WSAAsyncSelect() more than once, so it's also not recommended for the unnecessary overhead it incurs. > I have to admit that I don't like (ii). It makes it harder to divorce > comms code from the application. No offense meant to winflex, but if you need this divorce, then your application design needs reexamination. My guess is winflex has problems with the extra messages the superfluous WSAAsyncSelect() calls are generating. It also sounds a bit like you're trying to preserve message boundaries on a STREAM socket, which is another problem unrelated to FD_WRITE. If WSAAsyncSelect() is used properly, you end up with a clean and simple event-driven application. When you have data and you have a connnection, you send your data. When send() fails with WSAEWOULDBLOCK, you stop sending until you get an FD_WRITE message. Then you start sending again. Couldn't be easier. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From rcq@mailserv-D.ftp.com Fri Mar 25 05:59:22 1994 Received: from ftp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA25273; Fri, 25 Mar 1994 11:00:05 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 25 Mar 1994 11:00:05 -0500 Received: from rcq.oysters.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA24266; Fri, 25 Mar 94 10:59:22 EST Date: Fri, 25 Mar 94 10:59:22 EST Message-Id: <9403251559.AA24266@mailserv-D.ftp.com> To: pete@tecc.co.uk Subject: Re: getXbyY() 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 Fri Mar 25 10:59:08 1994] Originating-Client: oysters.ftp.com Content-Length: 373 > Short of biting the bullet and recoding using the (correct) aynch. > functions, what can I do? Have your customers contact support@ftp.com. It sounds like they are having a DNS and/or hosttable configuration problem. Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From pete@tecc.co.uk Fri Mar 25 17:43:11 1994 Received: from luggage.tecc.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11533; Fri, 25 Mar 1994 12:47:02 -0500 Received: from luggage.tecc.co.uk by luggage.tecc.co.uk id aa12166; 25 Mar 94 17:43 GMT To: winsock-hackers@sunsite.unc.edu Subject: Re: WSAAsynchSelect(), FD_WRITE etc In-Reply-To: Your message of "Fri, 25 Mar 1994 10:59:10 EST." <9403251559.AA24260@mailserv-D.ftp.com> Date: Fri, 25 Mar 1994 17:43:11 +0000 From: Pete Bentley Message-Id: <9403251743.aa12166@luggage.tecc.co.uk> In message <9403251559.AA24260@mailserv-D.ftp.com>, Bob Quinn writes: >> Hi Pete! >> >> [ Lucid explanation of interactions between socket state & FD_WRITE >> omitted] I was only considering STREAM sockets in the connected state. I just forgot to say so. :-) (sorry). >> > I have to admit that I don't like (ii). It makes it harder to divorce >> > comms code from the application. >> >> No offense meant to winflex, but if you need this divorce, then >> your application design needs reexamination. My guess is winflex >> has problems with the extra messages the superfluous WSAAsyncSelect() >> calls are generating. It also sounds a bit like you're trying to >> preserve message boundaries on a STREAM socket, which is another >> problem unrelated to FD_WRITE. >> There are two lumps of code here. One is the winflex application, the other is a C++ class library which hides winsock. The latter also implements stdio (ish) buffering, to make it easier for the application to talk line oriented protocols. I want the class library to be re-usable (in fact I have happily used it for other things) and for it to impose as few constraints as possible on the application. In particulr if ythe application is talking a complex protocol (eg winflex) I want it to be able to generate small amounts of data from various subroutines and submit it to the socket without worrying too much about FD_WRITE behaviour (separation of concerns). >> If WSAAsyncSelect() is used properly, you end up with a clean and >> simple event-driven application. When you have data and you have >> a connnection, you send your data. When send() fails with >> WSAEWOULDBLOCK, you stop sending until you get an FD_WRITE message. >> Then you start sending again. Couldn't be easier. The problem here with complex application protocols is recovering the application state. It's fine if the data is all ready to go beforehand, but if you want to generate the data on the fly from different places it gets painful. To oversimplify, I could (with winflex) generate a scratch file with all the data I wanted to send, which means generating user authorisation info, copying (possibly large) PostScript files in, generating cover page information (complex PostScript) and recipient information. Then state recovery becomes a simple matter of keeping an offset into a file, but at a price I don't really want to pay. The only way to conclude this kind of discussion is over beer & code walkthroughs..... Pete. From rcq@mailserv-D.ftp.com Sun Mar 27 05:44:33 1994 Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA23325; Sun, 27 Mar 1994 10:45:21 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Sun, 27 Mar 1994 10:45:20 -0500 Received: from rcq.hurricane.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA04418; Sun, 27 Mar 94 10:44:33 EST Date: Sun, 27 Mar 94 10:44:33 EST Message-Id: <9403271544.AA04418@mailserv-D.ftp.com> To: pete@tecc.co.uk Subject: Re: WSAAsynchSelect(), FD_WRITE etc 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 Sun Mar 27 10:44:22 1994] Originating-Client: hurricane.ftp.com Content-Length: 3460 > There are two lumps of code here. One is the winflex application, the > other is a C++ class library which hides winsock. The latter also > implements stdio (ish) buffering, to make it easier for the > application to talk line oriented protocols. I want the class library > to be re-usable (in fact I have happily used it for other things) and > for it to impose as few constraints as possible on the application. > In particulr if ythe application is talking a complex protocol (eg > winflex) I want it to be able to generate small amounts of data from > various subroutines and submit it to the socket without worrying too > much about FD_WRITE behaviour (separation of concerns). > > >> If WSAAsyncSelect() is used properly, you end up with a clean and > >> simple event-driven application. When you have data and you have > >> a connnection, you send your data. When send() fails with > >> WSAEWOULDBLOCK, you stop sending until you get an FD_WRITE message. > >> Then you start sending again. Couldn't be easier. > > The problem here with complex application protocols is recovering the > application state. It's fine if the data is all ready to go > beforehand, but if you want to generate the data on the fly from > different places it gets painful. To oversimplify, I could (with > winflex) generate a scratch file with all the data I wanted to send, > which means generating user authorisation info, copying (possibly > large) PostScript files in, generating cover page information (complex > PostScript) and recipient information. Then state recovery becomes a > simple matter of keeping an offset into a file, but at a price I don't > really want to pay. Ok, I (finally) understand all the considerations. I'll suggest just a couple of things, then (finally) shut-up. First, trying to equate a file-handle and socket is not easy. This is why the BSD folk created the concept of a "socket" rather than just extending or re-using the file-handle. I think you'll save your sanity by forgetting about trying to emulate stdio. Second, you can indeed get the seperation you want between your high- level code and the comm object you want to create, but you need to change the way you're doing it. To operate asynchronously your object should deal with the socket from start to finish. In other words, let your object call WSAStartup(), socket(), WSAAsyncSelect() at initialization (if not even connect() too) ...then closesocket(), WSACleanup() at termination. This way, your object will be completely socket aware, and you can write it to deal with all the socket states associated with asynchronous operation through the life of a connection/socket. Trying to deal at the low, atomic operation, level you're at now is problematic, as you've illustrated. You can stick with your current design, but you'd be better off using the SYNCHronous method (e.g. NOT asynch calls). Straight blocking or non-blocking socket operations will better fit your paradigm. > The only way to conclude this kind of discussion is over beer & code > walkthroughs..... When are beer marketeers going to pick up on that great combination!? I can see the advertisements now: "Can't find that bug? Shed some light on it with a ." Regards, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA From pete@tecc.co.uk Sun Mar 27 18:31:35 1994 Received: from luggage.tecc.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA01463; Sun, 27 Mar 1994 11:36:39 -0500 Received: from luggage.tecc.co.uk by luggage.tecc.co.uk id aa24969; 27 Mar 94 17:31 BST To: winsock-hackers@sunsite.unc.edu Subject: Re: WSAAsynchSelect(), FD_WRITE etc In-Reply-To: Your message of "Sun, 27 Mar 1994 10:44:33 EST." <9403271544.AA04418@mailserv-D.ftp.com> Date: Sun, 27 Mar 1994 17:31:35 +0100 From: Pete Bentley Message-Id: <9403271731.aa24969@luggage.tecc.co.uk> In message <9403271544.AA04418@mailserv-D.ftp.com>, Bob Quinn writes: >> Ok, I (finally) understand all the considerations. I'll suggest just >> a couple of things, then (finally) shut-up. >> >> First, trying to equate a file-handle and socket is not easy. This >> is why the BSD folk created the concept of a "socket" rather than >> just extending or re-using the file-handle. I think you'll save your >> sanity by forgetting about trying to emulate stdio. I couldn't agree more --- it was just another of my over-simplifications (sorry --- I wasn't expecting to be picked up on it). All I really do is provide buffering for semi-efficient character/line oriented socket I/O. There might be a vsprinf()-alike in there somewhere, too. I have to admit, I *do* miss not being able to fdopen() on a Windows socket. >> Second, you can indeed get the seperation you want between your high- >> level code and the comm object you want to create, but you need to >> change the way you're doing it. To operate asynchronously your >> object should deal with the socket from start to finish. In other >> words, let your object call WSAStartup(), socket(), WSAAsyncSelect() >> at initialization (if not even connect() too) ...then closesocket(), >> WSACleanup() at termination. This way, your object will be >> completely socket aware, and you can write it to deal with all the >> socket states associated with asynchronous operation through the life >> of a connection/socket. That's pretty much what it does. The only problems were i) I modelled the send()/FD_WRITE semantics wrong the first time ii) The 'right' way (my opinion, probably not worth discussing) involves letting the WinSock DLL handle the socket state during send() by changing the event mask semi-regularly. Current practice dictates against this, so I handle send() state myself which involves a fake FD_WRITE from time to time to kick-start things. >> You can stick with your current design, but you'd be better off using >> the SYNCHronous method (e.g. NOT asynch calls). Straight blocking or >> non-blocking socket operations will better fit your paradigm. Ah, but then I couldn't code the app to work with asynchronous callbacks so easily. :-) (which is how all zApp based applications work --- a bit like InterViews as far as my limited knowledge of InterViews goes). More to the point, it opens up the whole re-entrancy thing when you have (eg) dialogue boxes controlling TCP connections, so events are still flying about... Anyway, I now seem to have done it in a way which works with both PC/TCP 1.06 and PC/TCP 1.10 (differing send()/FD_WRITE handling) as well and Microsoft, Trumpet and (hopefully) PC-NFS. I gave up making assumptions that the Winsock DLL adheres closely to the spec and make make fewer demands of it --- things got better from when I made that decision. :-) Maybe it'll even work for more than one connection with LWP now. >> >> > The only way to conclude this kind of discussion is over beer & code >> > walkthroughs..... >> >> When are beer marketeers going to pick up on that great combination!? >> I can see the advertisements now: "Can't find that bug? Shed some >> light on it with a ." >> Something Dominos Pizza could capitalise on, too --- a 'hackers special' with an extra large pizza and a 6 pack...(Damn, I'm conforming to stereotypes again). Anyway, I now took the dependancy on the zApp application framework out of the socket classes, and should be making a new release of winflex sometime this week, in which case the code will appear on sgi.com and people can pull my style to pieces. :-) Maybe when I add support for asynch. getXbyY() calls and verify that accept() etc still work I'll make a seperate release of the library. It has one irritating feature at the minute --- it creates hidden windows for each socket to receive messages. These have to (I think) be children of one of the application's windows to ensure the messages actually get dispatched to my WindProc. That means at some point the app. has to explicitly call an initialisation function to tell the library what top-level HWND to use as a parent. If I could find an efficient way of finding the applications top-level window, I could get rid of the need for that call and user code becomes as simple as:- tcBufferedSocket *s = new tcBufferedSocket(SOCK_STREAM); s->Connect("myfaxhost.dom", "fax"); // etc Currently the only way I can see to do this is to find the current task's HTASK and iterate through the top level windows looking for one with the same HTASK. I can then get an HINSTANCE easily and start creating my child windows.... Pete. // Just a sad old Unix hacker who hides the Windows API behind C++ :-) From bryan%alex.com@gateway.alex.com Mon Mar 28 12:48:48 1994 Received: from post.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA27220; Mon, 28 Mar 1994 12:48:48 -0500 Received: from gateway.alex.com by post.demon.co.uk id aa25005; 28 Mar 94 18:17 GMT-60:00 Return-Path: Received: from SKID by woody.alex.com (4.1/SMI-4.1) id AA08156; Mon, 28 Mar 94 18:16:53 BST Date: Mon, 28 Mar 94 18:16:53 BST Message-Id: <9403281716.AA08156@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: I wrote: >>2) On restarting the application very quickly after it has just exited, the >>second socket will fail to connect() with WSAADDRINUSE. This is odd, because >>bind() on that socket has just succeeded. This conversation has continued in private email; I didn't notice that Bob (rfq@ftp.com) CC'd his first reply to the net. With his permission, I will draw the threads back together, and look for further opinions. The first thing to note is that I had got the DLL version number correct, but that this didn't matter, since the newer version (1.12 beta 1) behaves exactly the same. Bob gave an answer: >The reason bind() succeeds is because our native API doesn't have >a direct equivalent of bind(). We fake it by keeping track of >the ports used by each socket in our array of socket structures. >So, when you do a connect() it gets the message from the kernel >that there's already a socket in use (the fact that it's just >TIMEWAIT doesn't matter), which means you get WSAEADDRINUSE. Well, OK, it's a little deficiency in PC/TCP. But Bob goes on: >In general, client's need not bind() to a local port. It is >not recommended that they do, for the possibility of the very error >you are encountering. This seems strange to me. I pointed out that the Winsock spec itself gives an example of bind() which is almost the same as my own code. Bob doesn't think this important: >The keyword there is "almost." There's no connect(). I don't see that this is relevant, and Bob hasn't offered any suggestion of what else other than connect() might follow the fragment. Perhaps the person who wrote that part of the spec would like to tell us how it is meant to be used? Would anyone else like to comment on the utility of a bind() that can't reliably get you a free reserved port? Anyone else think that it is not recommended to call bind()? Bryan. From sr@mnfep.nn.inri.com Tue Apr 1 04:10:55 1994 Received: from mickey.mnfep.nn.inri.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA11744; Tue, 29 Mar 1994 09:05:49 -0500 Received: by mickey.mnfep.nn.inri.com id AA04896 (5.65c/IDA-1.4.4 for winsock-hackers@sunsite.unc.edu); Tue, 29 Mar 1994 09:10:55 -0500 Date: Tue, 29 Mar 1994 09:10:55 -0500 From: sr@mnfep.nn.inri.com Message-Id: <199403291410.AA04896@mickey.mnfep.nn.inri.com> To: winsock-hackers@sunsite.unc.edu Subject: Please subscribe sr@inri.com Please subscribe me at sr@inri.com Thank you Subu Rama sr@inri.com From sasdxk@unx.sas.com Wed Apr 2 04:50:38 1994 Received: from lamb.sas.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA06733; Wed, 30 Mar 1994 09:51:49 -0500 Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/10-28-91) id AA18448; Wed, 30 Mar 1994 09:51:44 -0500 Received: from skyhawk.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA07795; Wed, 30 Mar 1994 09:50:47 -0500 Received: by skyhawk.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA14787; Wed, 30 Mar 1994 09:50:39 -0500 From: Dave Kolb Message-Id: <199403301450.AA14787@skyhawk.unx.sas.com> Subject: Novell gethostname fails To: winsock-hackers@sunsite.unc.edu Date: Wed, 30 Mar 1994 09:50:38 -0500 (EST) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2076 Although it has worked in the past, I cannot currently get Novell's LWP4DOS winsock (3 levels of updates) to work anymore unless I have a hosts file with my own name in it. Other winsock functions seem to work fine once the maintenance was applied (WSASetBlockingHook used to fail also). My name is the only thing in the hosts file as all other names are resolved via the resolv file to the domain name servers just fine. Anyone else seen this problem or know what the unknown opcode 14 is that my DNS trace complained about? Novell hasn't a clue. The trace is appended below. WNT's winsock runs fine on this same hardware setup without any hosts file as do other winsock stacks. Thanks, Dave Kolb SAS institute req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: IQuery found dxkblue.pc.sas.com req: answer -> 130.96.2.71 6 (1038) id=8 Remote datagram from 130.96.2.71 port 1039, fd 6, len 27 Opcode 14 not implemented req: answer -> 130.96.2.71 6 (1039) id=25196 Remote datagram from 130.96.2.71 port 1039, fd 6, len 27 Opcode 14 not implemented req: answer -> 130.96.2.71 6 (1039) id=25196 Remote datagram from 130.96.2.71 port 1039, fd 6, len 27 Opcode 14 not implemented req: answer -> 130.96.2.71 6 (1039) id=25196 Remote -- Dave Kolb Compuserve: 72410,407@compuserve.com SAS Institute, Inc. EMAIL: sasdxk@unx.sas.com SAS Campus Drive - R3282 Phone: (919) 677-8000 x6827 Cary, NC 27513-2414 USA FAX: (919) 677-8123 From paul@atlas.dev.abccomp.oz.au Thu Apr 3 09:50:46 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA29826; Thu, 31 Mar 1994 08:09:26 -0500 Received: by usage.csd.unsw.OZ.AU id AA18239 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Thu, 31 Mar 1994 23:09:28 +1000 Received: by atlas (4.1/1.35) id AA25514; Thu, 31 Mar 94 14:50:47 EST Message-Id: <9403310450.AA25514@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 31 Mar 1994 14:50:46 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: winsock-hackers@sunsite.unc.edu Subject: What does send() returning 0 mean ? revisited 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 .... -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From paul@atlas.dev.abccomp.oz.au Thu Apr 3 08:53:24 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA00480; Thu, 31 Mar 1994 08:13:58 -0500 Received: by usage.csd.unsw.OZ.AU id AA18325 (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Thu, 31 Mar 1994 23:10:18 +1000 Received: by atlas (4.1/1.35) id AA25427; Thu, 31 Mar 94 13:53:25 EST Message-Id: <9403310353.AA25427@atlas> From: paul@atlas.abccomp.oz.au Date: Thu, 31 Mar 1994 13:53:24 -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 Mar 30,12:36am: /-------------------- |I wrote: | |>>2) On restarting the application very quickly after it has just exited, the |>>second socket will fail to connect() with WSAADDRINUSE. This is odd, because |>>bind() on that socket has just succeeded. | |This conversation has continued in private email; I didn't notice |that Bob (rfq@ftp.com) CC'd his first reply to the net. With his permission, |I will draw the threads back together, and look for further opinions. ... |[Bob Quinn said] |>In general, client's need not bind() to a local port. It is |>not recommended that they do, for the possibility of the very error |>you are encountering. | |This seems strange to me. I pointed out that the Winsock spec itself |gives an example of bind() which is almost the same as my own code. |Bob doesn't think this important: | |>The keyword there is "almost." There's no connect(). | |I don't see that this is relevant, and Bob hasn't offered any suggestion |of what else other than connect() might follow the fragment. Perhaps |the person who wrote that part of the spec would like to tell us how |it is meant to be used? | |Would anyone else like to comment on the utility of a bind() that |can't reliably get you a free reserved port? Anyone else think that |it is not recommended to call bind()? ...And the last sentence seems to give the whole problem a new twist. Let me restate what I think Bob was saying (and BOb, feel free to correct me if I am wrong!): Typically _clients_ do not need to call bind() - typically they do not need a special port number, they need to connect to a _server_ that listens to a special port number. So typically client programs do not call bind() before connect() - they let the connect() call perform an implicit bind() to a free port number - read the first paragraph of connect()'s Remarks section, and ignore the WSAEINVAL error message - it shouldn't be there in the Error Codes section. Typically only _servers_ need to bind() to a special port, in which case the missing next socket call in the code fragment on page 21/22 is LISTEN(), _not_ CONNECT(). 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(). 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. -- 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 |