From sunsite.unc.edu!winsock-hackers Tue Oct 26 22:37:12 1993 Date: Wed, 27 Oct 93 01:37:51 EDT Message-Id: <9310262311.AA01246@atlas> Reply-To: paul@atlas.abccomp.oz.au Originator: winsock-hackers@sunsite.unc.edu Sender: winsock-hackers@sunsite.unc.edu From: paul@atlas.abccomp.oz.au To: Multiple recipients of list Subject: Re: gethostname(). X-Listprocessor-Version: 6.0a -- ListProcessor by Anastasios Kotsikonas Status: OR Thus expounded Distinct TCP/IP on Oct 25,10:22pm: /-------------------- |Hi! | |The WINSOCK spec says that gethostname() returns a name that is |"guaranteed" to be successfully parsed by gethostbyname(). This |effectively means that gethostname() cannot return an internet |address in the formatt "a.b.c.d", because these are not parsed by |gethostbyname(). | |If a machine is getting its local IP address from RARP, BOOTP |or PPP, it only has a valid IP address and no name associated |with it. So in these case what should gethostname() return? |It cannot return the IP address and somehow returning an error |code does not seem to be the correct option. If it has to return an |error, what error code should it return????? There is a broader issue - what if the stack is configured with a name, but that name is not in the stacks host table or the DNS - in that case, normal processing would NOT resolve the name into an IP number. This gethostname() is usually used to find the stack's IP number, by calling gethostbyname() on the string returned by gethostname(). My feeling is the stack should provide some sort of dummy name if there is not one coded, and the gethostbyname/WSAgetHostByName should explicitly check for this string and return the local IP number, without going through the normal resolving process. That way, if RARP/BOOTP/etc is used to configure the IP number and there is no host name, gethostname should return "localhost" or something that only need be meaningful to the stack without recourse to the DNS or hosts file. Its a good question, that needs further clarification in the next spec.. | vikas | |========================================================== |Vikas Garg Phone : (408) 741-0781 |Distinct Corp. Fax : (408) 741-0795 |14395 Saratoga Av. E-Mail: vikas@distinct.com |Saratoga, CA 95070 |U.S.A. |========================================================== | \--------------------- {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 gabor.inference.com!inference.com!gloster Thu Jan 27 13:46:00 1994 Date: Thu, 27 Jan 94 13:50:20 PST From: "Vance M. Gloster" Message-Id: <9401272150.AA09238@quaestor> To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution content-length: 137 Status: OR UDP sockets Adding a standard interface to UDP sockets so that a standard Ping could be created. -Vance Gloster gloster@inference.com ???? ???? From gabor.inference.com!inference.com!gloster Thu Jan 27 13:48:34 1994 Date: Thu, 27 Jan 94 13:53:00 PST From: "Vance M. Gloster" Message-Id: <9401272153.AA09283@quaestor> To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution content-length: 231 Status: OR BOOTP support Explicit support for BOOTP which allows dialup connections to set their IP address dynamically at connection time. A standard interface for this should be explicitly required. -Vance Gloster gloster@inference.com ???? ???? From gabor.inference.com!inference.com!gloster Thu Jan 27 14:33:48 1994 Date: Thu, 27 Jan 94 14:39:21 PST From: "Vance M. Gloster" Message-Id: <9401272239.AA11350@quaestor> To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution content-length: 379 Status: OR Custom wrapper creation. As discussions on the winsock maillist have indicated, creating a DLL that would provide easy access to winsock from another language (i.e., Visual BASIC) is both desirable and difficult to do portably on Winsock 1.1. The 2.0 product should explicitly support creating portable layers on top of Winsock in a DLL. -Vance Gloster gloster@inference.com ???? ???? From relay2.uu.net!uunet.uu.net!tcemail!is3.indy.tce.com!fisherm Fri Jan 28 10:37:33 1994 Reply-To: tcemail!FisherM@is3.indy.tce.com Return-Receipt-To: tcemail!is3.indy.tce.com!FisherM@jsbus.com Date: Fri, 28 Jan 94 13:23:00 PST From: Fisher Mark Subject: WinSock 2.0 -- Raw Sockets for Ping To: "Windows Sockets 2.0" Message-Id: <2D49838A@MSMAIL.INDY.TCE.COM> Encoding: 12 TEXT X-Mailer: Microsoft Mail V3.0 Status: OR The most needed item is mandatory raw sockets support to the level required by ping. Ping is what everyone uses for initial testing of connections -- it should always be able to be written for a conforming WinSock implementation. ====================================================================== 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 chaos.tci.com!klaven.tci.com!jspoffor Mon Jan 31 14:49:55 1994 Message-Id: <9401312254.AA04906@chaos.tci.com> From: jspoffor Date: Mon, 31 Jan 94 15:50 To: martinh Subject: Other Protocols in Winsock 2.0 Status: OR I'd really like to see the inclusion of other protocols, and if I had to pick only one, I'd say add IPX/SPX. Perhaps it wouldn't be manditory, but there should be some way of determining if it supports IPX/SPX (as opposed to TCP/IP) at start up time. Also, the necessary structures and control differences would need to be included in the specification. Right now, I have to add my own abstraction layer to deal with doing SNMP over IPX or IP. It would be great not to need to do that. Jason Spofford jspoffor@klaven.tci.com ???? ???? From chaos.tci.com!klaven.tci.com!jspoffor Mon Jan 31 14:51:43 1994 Message-Id: <9401312254.AA04910@chaos.tci.com> From: jspoffor Date: Mon, 31 Jan 94 15:50 To: martinh Subject: SLIP and CSLIP in Winsock 2.0 Status: OR It would be great if there was a standard way to support SLIP and CSLIP through Winsock. Jason Spofford jspoffor@klaven.tci.com ???? ???? From chaos.tci.com!klaven.tci.com!jspoffor Mon Jan 31 14:51:43 1994 Message-Id: <9401312254.AA04902@chaos.tci.com> From: jspoffor Date: Mon, 31 Jan 94 15:50 To: martinh Subject: RAW SOCKETS in Winsock 2.0 Status: OR I'm an application developer. I'd like winsock implementations to have to support PING by providing access to ICMP (i.e. RAW SOCKETS). I'm sure you have heard this before, I'd just like to add my voice. ???? ???? From relay2.pipex.net!firefox.co.uk!marke Wed Feb 2 03:45:26 1994 From: Mark Edwards X-Mailer: SCO System V Mail (version 3.2) To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution Date: Wed, 2 Feb 94 11:11:10 gmt Message-ID: <9402021111.aa08003@ffsco.firefox.co.uk> Status: OR Hi Martin, Long time no see, hope all is well. Item 1. Short Desc: Winsock 2 requires the capability for Multi-protocol support. Longer Desc: This is reasonably easy to provide, since all the DLL needs do is communicate to the correct stack by checking the protocol family passed in the socket() call. It would probably, be a good idea to include an area in the WSADATA structure that holds the values of the protocol families that the DLL currently knows about and can handle. This is not important to stack vendors who only produce one stack, but affects vendors such as Microsoft, JSB and Firefox. 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 relay2.pipex.net!firefox.co.uk!marke Wed Feb 2 03:46:34 1994 From: Mark Edwards X-Mailer: SCO System V Mail (version 3.2) To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution Date: Wed, 2 Feb 94 11:12:24 gmt Message-ID: <9402021112.aa08010@ffsco.firefox.co.uk> Status: OR Martin, Item 2. Short Desc: A mechanism for retrieving Service definitions from a network. Longer Desc: Sockets as it stands is great for protocols where the address information is known by the application or entered by the user. It cannot cope with broadcast service definitions where the user has no idea of the network address. The means for retrieving service definitions from a network is required for protocols such as DEC LAT, IPX/SPX (SAP) and, dare I say it, Firefox. We have currently implemented such a mechanism, and think that it shows promise as a generic 'Extra functionality' handler. 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 relay2.pipex.net!firefox.co.uk!marke Wed Feb 2 03:47:57 1994 From: Mark Edwards X-Mailer: SCO System V Mail (version 3.2) To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution Date: Wed, 2 Feb 94 11:13:45 gmt Message-ID: <9402021113.aa08016@ffsco.firefox.co.uk> Status: OR Martin, Item 3. Short Desc: A clearing house for new protocol families and associated address types. Longer Desc: Firefox at the moment have implemented a protocol family with an address structure. The protocol family is obviously chosen at random and at the moment conflicts with nobody else. If vendors are encouraged to add new protocol types then we need to ensure that the protocol family numbers do not clash. 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 relay2.pipex.net!firefox.co.uk!marke Wed Feb 2 03:49:26 1994 From: Mark Edwards X-Mailer: SCO System V Mail (version 3.2) To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution Date: Wed, 2 Feb 94 11:15:10 gmt Message-ID: <9402021115.aa08022@ffsco.firefox.co.uk> Status: OR Martin, Item 4. Short Desc: A mechanism for broadcasting service definitions on a network. Longer Desc: If Winsock 2 caters for the retrieval of broadcast service definitions, then it should also be capable of accepting a service definition from an application to be broadcast on the network. 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 sun.com!suneast.east.sun.com!rwolin Wed Feb 2 14:11:08 1994 Date: Wed, 2 Feb 1994 17:16:48 +0500 From: Ross Wolin - PC Networking Engineering CONTRACTOR Message-Id: <9402022216.AA11225@denmark.East.Sun.COM> To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution Content-Length: 378 Status: OR Callback procedures for asynchronous sockets. Currently asynchronous sockets notify processes of socket events by sending a Window message. I would like to see asynchronous socket have the option to call a callback routine OR send a window message. This functionality would make asynchronous C++ socket objects work much better... Ross Wolin rwolin@suneast.sun.com "Ni!" ???? ???? From calypso-2.oit.unc.edu!winsock-hackers Mon Feb 7 15:46:59 1994 Date: Mon, 7 Feb 1994 18:39:36 -0500 Message-Id: <9402072350.AA04134@atlas> Reply-To: paul@atlas.abccomp.oz.au Originator: winsock-hackers@sunsite.unc.edu Sender: winsock-hackers@calypso-2.oit.unc.edu From: paul@atlas.abccomp.oz.au To: Multiple recipients of list Subject: Winsock v2 X-Listprocessor-Version: 6.0a -- ListProcessor by Anastasios Kotsikonas Status: ORP History: Replied to on 18 Feb 94 So we're well into the new year. Is discussion of features/changes for v2 going to take place on this winsock-hackers list, or on another list I don't yet know about? -- 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 halon.sybase.com!sybase.com!william Tue Feb 8 12:13:46 1994 From: William Wong Message-Id: <9402082013.AA23594@mercury.sybgate.sybase.com> Subject: Windows Sockets 2 Contribution To: martinh@jsbus.com Date: Tue, 8 Feb 94 12:13:22 PST X-Mailer: ELM [version 2.3 PL0] content-length: 348 Status: OR Winsock 2.0 should add support for BOTH RFC 793 and RFC 1122 styles of Out-Of-Band data. Most Unix TCP/IPs use RFC 793 Out-Of-Band data, e.g. Sun4, HP, RS6000, etc. However, Solaris is getting popular and it is using RFC 1122 OOB. Winsock 2.0 implementation should support both and make it user configurable to switch between the two. William ???? ???? From relay1.uu.net!netmanage.com!tmima Wed Feb 9 16:40:34 1994 Message-Id: Date: Wed, 9 Feb 94 17:44:42 PST Reply-To: Tmima Koren From: Tmima Koren To: Martin Hall Subject: Windows Sockets 2 Contribution Status: OR shared sockets Set 'shared' attribute to a socket, maybe with setsockopt(). A shared socket can be passed and used by all tasks. ???? ???? From magnolia.banyan.com!banyan!eng!mike=procopio Thu Feb 10 10:58:05 1994 Date: Thu, 10 Feb 94 14:09:49 EST From: Mike=Procopio%Eng%Banyan@magnolia.banyan.com Subject: re:Windows Sockets 2 Contribution To: martinh@jsbus.com Cc: Bcc: Message-ID: <9402101058.aa15682@jsbus.jsbus.com> Status: OR I would like to see the spec address concurrent access of multiple address families in a coherent (common across all implementations) way. Currently, on DOS/Windows 3.1 it is necessary for an APP to use LoadLibrary(), and GetProcAddress() in order to concurrently access winsock.dll's from multiple providers providing support for different address families. There should be a standard mechanism. procopio@banyan.com ???? ???? From magnolia.banyan.com!banyan!eng!mike=procopio Thu Feb 10 10:59:47 1994 Date: Thu, 10 Feb 94 14:12:19 EST From: Mike=Procopio%Eng%Banyan@magnolia.banyan.com Subject: re:Windows Sockets 2 Contribution To: martinh@jsbus.com Cc: Bcc: Message-ID: <9402101059.aa15843@jsbus.jsbus.com> Status: OR The semantics of alternate address families need to be defined. Currently, the winsock semantic definition is restricted to TCP/IP. It needs to address other address families as well: IPX/SPX, ISO, etc.. procopio@banyan.com ???? ???? From magnolia.banyan.com!banyan!eng!mike=procopio Thu Feb 10 11:04:27 1994 Date: Thu, 10 Feb 94 14:16:08 EST From: Mike=Procopio%Eng%Banyan@magnolia.banyan.com Subject: re:Windows Sockets 2 Contribution To: martinh@jsbus.com Cc: Bcc: Message-ID: <9402101104.aa16117@jsbus.jsbus.com> Status: OR Winsock should be enlarged to provide the concept of "in-system" usage. Currently, winsock defines an API restricted to windows applications. There is a real need for a standard in-system interface as well. The analogy is in-system is to winsock what TPI is to TLI. procopio@banyan,.com ???? ???? From relay1.uu.net!netmanage.com!tmima Thu Feb 10 11:52:02 1994 Message-Id: Date: Wed, 9 Feb 94 17:44:42 PST Reply-To: Tmima Koren From: Tmima Koren To: Martin Hall Subject: Windows Sockets 2 Contribution Status: OR set/get/remove ARP table entry ???? ???? From relay1.uu.net!netmanage.com!tmima Thu Feb 10 11:52:43 1994 Message-Id: Date: Wed, 9 Feb 94 17:44:42 PST Reply-To: Tmima Koren From: Tmima Koren To: Martin Hall Subject: Windows Sockets 2 Contribution Status: OR gethostid() ???? ???? From relay1.uu.net!netmanage.com!tmima Thu Feb 10 12:34:01 1994 Message-Id: Date: Wed, 9 Feb 94 17:44:42 PST Reply-To: Tmima Koren From: Tmima Koren To: Martin Hall Subject: Windows Sockets 2 Contribution Status: OR raw ICMP/IP ???? ???? From mail.netcom.com!next.distinct.com!vikas Mon Feb 14 11:24:39 1994 From: Vikas Garg Message-Id: <9402141929.AA02003@distinct.com> Subject: Windows Socket 2.0 Contributions To: Martin Hall Date: Mon, 14 Feb 1994 11:29:03 -0800 (PST) Cc: Oliver Spaeth X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 691 Status: OR RAW SOCKETS Some level of support for the raw sockets should be included in the specs. Wether the access is to be at the ICMP level or the IP level should also be clarified. You must me sick of this request by now, so I will leave it at this :-) Vikas -- ========================================================== Vikas Garg Phone : (408) 741-0781 Distinct Corp. Fax : (408) 741-0795 12901 Saratoga Ave., Ste. 4 E-Mail: vikas@distinct.com Saratoga, CA 95070 U.S.A. ========================================================== ???? ???? From mail.netcom.com!next.distinct.com!vikas Mon Feb 14 11:36:51 1994 From: Vikas Garg Message-Id: <9402141941.AA02022@distinct.com> Subject: Windows Socket 2.0 Contributions To: Martin Hall Date: Mon, 14 Feb 1994 11:41:12 -0800 (PST) Cc: Oliver Spaeth X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 976 Status: OR WSAAsyncSelect() At this point in time I am sick of all the FD_@#$% discussions, whatever way they are supposed to be posted, PLEASE remove the ambiguities. i) Should FD_CLOSE be posted when the connection goes into the FIN_WAIT state or when it goes into the FIN_WAIT state AND there is no data to be read. ii) Should FD_CLOSE be posted once only or for every WSAAsyncSelect call? iii) Should FD_WRITE be posted only on connect() or accept() or also when WSAAsyncSelect() is called AFTER a successful connect() or accept(). ========================================================== Vikas Garg Phone : (408) 741-0781 Distinct Corp. Fax : (408) 741-0795 12901 Saratoga Ave., Ste. 4 E-Mail: vikas@distinct.com Saratoga, CA 95070 U.S.A. ========================================================== ???? ???? From netcom3.netcom.com!next.distinct.com!vikas Mon Feb 14 11:41:49 1994 From: Vikas Garg Message-Id: <9402141945.AA02036@distinct.com> Subject: Windows Socket 2.0 Contributions To: Martin Hall Date: Mon, 14 Feb 1994 11:45:09 -0800 (PST) Cc: Oliver Spaeth X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 541 Status: OR Sharing of Sockets among applications The topic says it all, you must be sick of this request also. Vikas -- ========================================================== Vikas Garg Phone : (408) 741-0781 Distinct Corp. Fax : (408) 741-0795 12901 Saratoga Ave., Ste. 4 E-Mail: vikas@distinct.com Saratoga, CA 95070 U.S.A. ========================================================== ???? ???? From mail.netcom.com!next.distinct.com!vikas Mon Feb 14 11:44:52 1994 From: Vikas Garg Message-Id: <9402141949.AA02047@distinct.com> Subject: Windows Socket 2.0 Contributions To: Martin Hall Date: Mon, 14 Feb 1994 11:49:09 -0800 (PST) Cc: Oliver Spaeth X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 919 Status: OR Multiple Versions Now that the situation to have multiple versions actually exists, can a winsock dll support multiple versions?? I would recommend against it since it can cause a lot of headaches if an application is using 2.0 and an intermediate DLL is using 1.1. If multiple version support is to be allowed, then please clarify how this problem is to be resolved also the version requested should not be ignored in subsequent calls to WSAStartup (page 108 second para.) Vikas -- ========================================================== Vikas Garg Phone : (408) 741-0781 Distinct Corp. Fax : (408) 741-0795 12901 Saratoga Ave., Ste. 4 E-Mail: vikas@distinct.com Saratoga, CA 95070 U.S.A. ========================================================== ???? ???? From netcom3.netcom.com!next.distinct.com!vikas Mon Feb 14 11:48:01 1994 From: Vikas Garg Message-Id: <9402141951.AA02058@distinct.com> Subject: Windows Sockets 2.0 Contributions To: Martin Hall Date: Mon, 14 Feb 1994 11:51:16 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 666 Status: OR Hosts List Some standard way for the applications to retrieve the list of available hosts. Maybe a function that returns the hosts as a linked list, or a standard way of saving the hosts in a file in the windows directory. Vikas -- ========================================================== Vikas Garg Phone : (408) 741-0781 Distinct Corp. Fax : (408) 741-0795 12901 Saratoga Ave., Ste. 4 E-Mail: vikas@distinct.com Saratoga, CA 95070 U.S.A. ========================================================== ???? ???? From netcom3.netcom.com!next.distinct.com!vikas Tue Feb 15 21:30:11 1994 From: Vikas Garg Message-Id: <9402160115.AA04352@distinct.com> Subject: Windows Socket 2.0 Contribution To: Martin Hall Date: Tue, 15 Feb 1994 17:15:17 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 799 Status: ORP History: Replied to on 18 Feb 94 Yielding by an application Can an application sit in a tight loop waiting on a select() without yielding control at all? The current specs say that this is illegal, however lot of applications (including WSAT) use this programming model. I hope we can either clarify it a bit more in the next version, or remove the requirement for applications to yield... Vikas -- ========================================================== Vikas Garg Phone : (408) 741-0781 Distinct Corp. Fax : (408) 741-0795 12901 Saratoga Ave., Ste. 4 E-Mail: vikas@distinct.com Saratoga, CA 95070 U.S.A. ========================================================== ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16 13:28:25 1994 Date: Wed, 16 Feb 94 13:34:32 PST From: David B Andersen Message-ID: <940216133432_8@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/16/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 1. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #1: Replace vendor-specific Winsock.DLLs with a single DLL Description: Existing Winsock implementations are all vendor-specific since no standard interface is defined for the interface between Winsock.DLL and protocol stacks. Version 2 of Winsock should change the model by defining such an interface (subsequently referred to as a Service Provider Interface or SPI). Motivation: Some level of ambiguity remains in the current version of the Winsock spec which results in subtle but sometimes crucial differences in how various Winsock implementations behave. Having a single Winsock DLL would ensure more uniform behavior, while allowing stack vendors to avoid duplication of effort. (Let's free up their resources so they can concentrate on improved versions of their stacks!) This also paves the way for multiprotocol support as outlined in our proposed extension #2. Semantics: A Winsock SPI specification would need to be created. An ini file will also need to be defined for the Winsock DLL which would provide it with the information requried to discover what underlying stacks were present and enable them to be loaded as required. Intel is prepared to make additional suggestions for a SPI specification and ini file format if the forum wishes to pursue this proposal further. ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16 13:31:23 1994 Date: Wed, 16 Feb 94 13:37:09 PST From: David B Andersen Message-ID: <940216133709_4@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/16/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 2. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #2: Support multiple transport protocols simultaneously Description: The Winsock interface should be generalized so as to provide access to any transport layer protocol. Furthermore, this should be done in such a way that at single app may have simultaneous access to multiple protocol stacks. While a unified addressing scheme that works across all protocols would also be desirable, so too would solving world hunger. For pragmatic reasons we suggest that Winsock version 2 not try and include a universal addressing model. Rather, it should be entirely neutral with respect to the addressing format of each underlying transport protocol. Motivation: While TCP/IP is an essential protocol stack, in the PC space there are many others that are very important as well (e.g. IPX, NetBIOS, DECNET, Vines, etc.). Application developers should not be required to utilize multiple APIs in order to host their application on multiple transports. Similarly, it is very possible that the server side of a client/server application may need to support various clients that do not all utilize the same transport protocol. Semantics: This proposal also requires that a SPI and ini file format be defined for Winsock as mentioned in our proposed extension #1. Intel is prepared to make additional suggestions for a SPI specification and ini file format if the forum wishes to pursue this proposal further. Implementation of this suggestion would also require that the API verbage be carefully edited to remove the existing bias towards and assumption of TCP/IP. A few new functions are needed to allow an application to evaluate the available transport choices and determine which transport to use when creating new sockets or using the getXbyY database routines. We propose the creation of a new WSA function for enumerating through the various service providers. Syntax is as follows: int PASCAL FAR WSAEnumProviders ( FARPROC lpfnCallback, int iAddressFamily); lpfnCallback Specifies the procedure instance address of the callback function to be invoked by Winsock.DLL for each Service Provider. iAddressFamily Specifies the address family that any enumerated Service Provider should support. This can be used as a filter, so that an application can get a list of Service Providers that support, e.g., AF_INET addresses. To get a list of every Service Provider, this parameter should be zero. This function is used to enumerate the Service Providers registered with and therefore accessible from the Winsock.DLL. It allows a descriptive text string, Service Provider Key, address family, socket types, and length of the address (in bytes) for each registered Service Provider to be retrieved. WSAEnumProviders() uses the standard Windows enumeration procedure using a "callback" function. The callback function is called once for each Service Provider registered in the "Winsock.ini" that matches the address family. This will be repeated until either the callback function returns zero or the end of the list of Service Providers is reached. The prototype of the callback function is as follows: int PASCAL FAR CallbackFunc( LPSTR lpszDescription, char FAR * ProviderKey, int iAddressFamily, int FAR * lpSocketType, int iAddressLength ); CallbackFunc is a placeholder for the application- supplied function name. The actual callback function must reside in a DLL or application module and be exported in the module definition file. You must use MakeProcInstance() to get a procedure-instance address for the callback function. The callback function must return nonzero to continue enumeration; to stop enumeration, it must return zero. lpSocketType points to a 0-terminated integer array indicating all the socket types supported by the Service Provider identified by ProviderKey along with a text description lpszDescription. The address family supported by the Service Provider is specified by iAddressFamily, and the (maximum) length of the address (in bytes) by iAddressSize, which allows applications to allocate a big enough buffer for address in this address family. In addition, we propose a new WSA function to allow an application to specify a particular service provider to use when creating new sockets and when accessing the getXbyY database routines. Syntax for this function is as follows: int PASCAL FAR WSAProviderSelection ( char FAR * ProviderKey ); ProviderKey The Key of the Service Provider to be selected. Remarks This function selects the Service Provider to be used for the current task until the next invocation of this function. Winsock functions which may be affected by this function include socket(), getXbyY(), and WSAAsyncGetXByY(). Applications can eliminate any pre-selected Service Provider by setting ProviderKey to be NULL. This indicates to the Winsock DLL that it should determine for itself which service provider to use based on the socket type and address family parameters to the socket() call. Whenever this function is used to set the provider selection to NULL, the default database provider as specified in the Winsock ini file is used for getXbyY functions. The provider keys of Service Providers can be obtained by using WSAEnumProviders(). Finally, it is necessary to ignore the value of the iMaxUdpDg field in the WSAData structure which is obtained via the WSAStartup() function. As a replacement for this, we propose a new get-only socket option: SO_MAX_DG_SIZE. ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16 13:36:00 1994 Date: Wed, 16 Feb 94 13:42:10 PST From: David B Andersen Message-ID: <940216134210_2@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/16/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 3. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #3: Expand the list of socket types and adopt a more desriptive naming convention Description: If Winsock provides access to protocols other than TCP/IP it will need to support more than just the SOCK_DGRAM and SOCK_STREAM socket types. We propose an expanded set of socket types that utilize a more descriptive and uniform naming convention. We do not advocate that service providers be required to support all or any particular set of socket types, with the exception that support for raw sockets (SOCK_RAW) should be mandatory. Some of the communications properties which should be supported are: connectedness, reliability, preservation of transmission boundaries, directionality and isochronicity. Motivation: Sockets are typed according to the communication properties visible to a user. Socket type names should be chosen to reflect the essential attributes of the corresponding socket. Other transport protocols support communications properties different from those available within TCP/IP. In particular, protocol stacks that are optimized for real-time multimedia applications have unique properties which must be accessible to an application. Proposed Semantics: We propose that socket type naming be based on the following convention: SOCK_RAW or SOCK_ [ REL | UNREL ][ _ISOCH ][ _UNISEND | _UNIRECV ] [_STREAM | _DGRAM | _DSTREAM ] Raw sockets provide a mechanism to bypass the usual protocol layers and are very much dependent on the particulars of each service provider. Service providers should be required to support raw sockets. [ REL | UNREL ] indicates whether or not the socket provides reliable communication. Reliability implies that the transport will ensure that all transmitted information arrives at the remote end or, failing in its attempts to accomplish this, will inform the application that reliable communication with the designated endpoint is currently not possible. [ _ISOCH ] indicates that the socket supports isochronous communications in which the time intervals between successive transmissions are (apparently) maintained throughout the network and reflected at the receiving end. [ _UNISEND | _UNIRECV ] restricts a socket to be uni- directional and allows only send or receive operations as indicated. Otherwise, all sockets are bi-directional. [ _STREAM | _DSTREAM | _DGRAM ] indicates whether the socket is connection-oriented (STREAM and DSTREAM) or connectionless (DGRAM). Connection-oriented, stream style sockets guarantee that information arriving at the receiving application will appear in correct sequence and without duplication. Note that this does not imply reliability (guaranteeing that all of the information will arrive). Rather it ensures that information which does arrive will be unduplicated and in correct sequence. Connectionless sockets (DGRAM), do not possess stream attributes and hence may provide information which is duplicated and/or out of sequence. The difference between a STREAM and a DSTREAM socket is that message boundaries are not preserved in the former(i.e. a byte stream) and are preserved in the latter (i.e. a message stream). Using this naming convention for socket types, the two styles of communication supported by TCP/IP (TCP streams and UDP datagrams) would be referred to as SOCK_REL_STREAM and SOCK_UNREL_DGRAM respectively. To maintain compatibility with existing socket-based applications, the Winsock header file would include alias definitions for the familiar SOCK_STREAM and SOCK_DGRAM socket types. ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Wed Feb 16 13:38:06 1994 Date: Wed, 16 Feb 94 13:43:26 PST From: David B Andersen Message-ID: <940216134326_4@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/16/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 4. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #4: Provide a means for sockets to be shared across applications Description: We believe it is essential that a paradigm for socket sharing be available in Winsock that is applicable to Win 3.1 as well as the Chicago and NT environments. We are uncomfortable with the approach of simply declaring that socket values must be globally unique while removing any existing checks that force the using and owning tasks to be the same. In environments such as Chicago and NT a socket can be used as a file descriptor and we must assume, therefore, that like file descriptors, socket values will only have meaning within the context of the owning task. Motivation: Shared sockets have been frequently referred to on the net as a desirable feature for version 2. In our own work with multimedia communications we have run across numerous instances where this capability would lead to simplified implementation. Semantics: We propose a new construct, which we refer to as a "virtual socket", as a mechanism to avoid these difficulties. Virtual socket are created in the context of the source task by supplying an existing, local socket descriptor and a handle to the target task (which could be the same task as the source task) for which the virtual socket will be used: SOCKET vs ; vs = WSADuplicateSocket( SOCKET s, HTASK hTargetTask ); To get the target task's handle, it will generally be necessary to use some form of interprocess communication (IPC), e.g., DDE and PostAppMessgage () in Windows 3.1, or named pipe and shared memory in Windows NT. Since vs is only valid in the context of the target task, the source task must pass the value of the virtual socket to the target task, also via your favorite IPC mechanism. Virtual sockets may be used in all places where regular sockets are used and are, in fact, indistinguishable from them. Virtual sockets derived from a common underlying socket share all aspects of the underlying shared socket with the exception of the notification mechanism. Reference counting is employed to ensure that the underlying shared socket is not closed until the last virtual socket is closed. Since the collection of attributes which comprise a virtual socket's option set is shared, setting any socket option may have a global effect. For example, if one task uses ioctlsocket() on a virtual socket to set it into non- blocking mode, this change is visible to all of the virtual sockets that reference the underlying shared socket. Each virtual socket has an independent notification mechanism which conforms to the usual Winsock conventions. For example, two tasks may wish to share a socket and operate in a cooperative fashion where one is the sender and the other the receiver. Each task may arrange for notification appropriate to its role. In the pathological case of two or more tasks sharing an underlying socket and each requesting asynchronous notification when data is ready to be read (foolish thing to do that this may be), all such tasks will receive their stipulated message in an unspecified sequence. The first task to perform a read will get some or all of the available data, the others will get what's left, if any. In other words, in all cases it is completely up to tasks which share a socket to coordinate their access to the socket. As an interesting aside, we note that simply invoking the WSADuplicateSocket() function on a socket s, causes s itself to become a virtual socket which references the original (and now underlying) socket. ???? ???? From intelhf.intel.com!ccm!david_b_andersen Thu Feb 17 15:42:39 1994 Date: Thu, 17 Feb 94 15:49:16 PST From: David B Andersen Message-ID: <940217154916_7@ccm.hf.intel.com> To: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM, martinh@jsbus.com Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/17/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 5. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #5: Provide support for protocol stacks which allow send() and recv() operations within interrupt context. Description: Some transport stacks allow an application to minimize latency and maximize throughput by invoking the send and receive operations from within interrupt context. A means should be provided to determine which transport stacks support this capability. Also the application must have a means to indicate to the Winsock DLL that a particular send or receive invocation is occurring within interrupt context. Motivation: Apps which send media streams over communications channels are often very sensitive to latency variations. By supporting send and receive operations in interrupt context the amount of variance in perceived latency can be minimized. Also, by supporting this capability at the API level, we encourage more stack vendors to support this feature. Semantics: We propose that a new get-only socket option be defined: SO_INTERRUPT. This option would be used by a service provider to indicate whether or not it supported interrupt context operations. Also, we propose the definition of an additional bit in the flags parameter used with send(), sendto(), recv() and recvfrom(). This bit would be called MSG_INTERRUPT and would be used by the app to indicate to the Winsock DLL that the particular send or receive operation was being performed in interrupt context. ???? ???? From intelhf.intel.com!ccm!david_b_andersen Thu Feb 17 15:45:29 1994 Date: Thu, 17 Feb 94 15:52:07 PST From: David B Andersen Message-ID: <940217155207_6@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/17/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 6. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #6: Provide callback notification Description: Applications should be able to select a callback style of notification in addition to the current Windows message based notification mechanism. This would be the only notification mechanism available for apps that perform send and receive operation from within interrupt context. The callback notification method should also allow an application to supply an uninterpreted token as a parameter to the notification request function, which is subsequently returned to the app as a parameter of the callback function. Motivation: This is being proposed primarily as a means to support interrupt context send and receive operations. However, significant additional value is added by including the user supplied token. Semantics: We propose the a new WSA function be defined for requesting callback notification: int PASCAL FAR WSACallbackSelect ( SOCKET s, FARPROC lpfnCallback, DWORD dwCallbackData, long lEvent ); s A descriptor identifying the socket for which event notification is required. lpfnCallback The procedure instance address of the callback function to be invoked by Winsock.DLL whenever a registered network event happens. dwCallbackData A callback data passed back to the application in the callback. This object is not interpreted by Winsock implementation. lEvent A bit mask which specifies a combination of network events in which the application is interested. This function will enable the function-based callback mechanism for the specified socket. WSACallbackSelect() is designed to get around the potential Windows message delay introduced by the WSAAsyncSelect() mechanism in order to support delay-sensitive applications. The callback function will be invoked whenever Winsock detects any of the network events specified by the lEvent parameter. The socket for which notification is required is identified by s. The dwCallbackData will be passed back to the application along with the callback. This function automatically sets socket s to non- blocking mode. The prototype of the callback function is as follows: VOID PASCAL FAR CallbackFunc( SOCKET s, long lEvent, int ErrorCode, DWORD dwCallbackData ); ???? ???? From intelhf.intel.com!ccm!david_b_andersen Thu Feb 17 15:45:52 1994 Date: Thu, 17 Feb 94 15:52:09 PST From: David B Andersen Message-ID: <940217155209_7@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock ver 2 Status: OR Text item: Text_1 02/17/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 7. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #7: Socket groups Description: We propose that the notion of a socket group be introduced as a means for an application (or cooperating set of applications) to indicate to an underlying service provider that a particular set of sockets are related and that the group thus formed has certain attributes. Proposed group attributes include relative priorities of the individual sockets within the group and a group quality of service specification. A new function is also proposed to allow an application to enumerate through the member sockets of a group. Motivation: Applications needing to exchange multiple media streams over the network are benefited by being able to establish a specific relationship among the set of sockets being utilized. As a minimum this might include a hint to the service provider about the relative priorities of the media streams being carried. For example, a conferencing application would want to have the socket used for carrying the audio stream be given higher priority than that of the socket used for the video stream. Furthermore, there are transport providers (e.g. digital telephony and ATM) which can utilize a group quality of service specification to determine the appropriate characteristics for the underlying call. The sockets within this group would then be multiplexed in the usual manner over this call. By allowing the application to identify the sockets that make up a group and to specify the required group attributes, such service providers can operate with maximum effectiveness. Semantics: We propose that the grouping of sockets be performed at the time when a connection request is made or when incoming socket connections are accepted. This would include both the creation of new groups and the addition of a socket to an existing group. Also, we suggest that two different types of groups be supported: constrained and unconstrained. In all cases sockets to be grouped must be associated with the same service provider. Sockets joined into an unconstrained group may have any host as their destination. Sockets joined to a constrained group must all have the same host as their destination (although the port number portion of their destination addresses may certainly differ). The syntax for a WSA version of connect would be as follows: int PASCAL FAR WSAConnectEx ( SOCKET s, const struct sockaddr FAR * name, int namelen, GROUP g, char FAR * lpSFlowspec, int iSFlowspecLen, char FAR * lpGFlowspec, int iGFlowspecLen ); s A descriptor identifying an unconnected socket. name The name of the peer to which the socket is to be connected. namelen The length of the name. g The identifier of the socket group. lpSFlowspec A pointer to the flow spec for socket s. iSFlowspecLen The length of the flow spec for socket s. It must be larger than or equal to the size of struct FLOWSPEC. lpGFlowspec A pointer to the flow spec for the socket group to be created, if the value of parameter g is SG_CONSTRAINED_GROUP. iGFlowspecLen The length of the flow spec for the socket group to be created, if the value of parameter g is SG_CONSTRAINED_GROUP. It must be larger than or equal to the size of struct FLOWSPEC. This function is used to create a connection to the specified destination. For connection- oriented sockets (e.g., type SOCK_STREAM), an active connection is initiated to the foreign host using name (an address in the name space of the socket;). When the socket call completes successfully, the socket is ready to send/receive data. For a connectionless socket (e.g., type SOCK_UNREL_DGRAM), the operation performed by WSAConnectEx() is merely to establish a default destination address which will be used on subsequent send() and recv() calls. If the socket, s, is unbound, unique values are assigned to the local association by the system, and the socket is marked as bound. Note that if the address field of the name structure is all zeroes, WSAConnectEx() will return the error WSAEADDRNOTAVAIL. Parameter g is used to indicate the appropriate actions on socket groups: if g is an existing socket group id, add s to this group, provided all the requirements set by this group are met; or if g = SG_UNCONSTRAINED_GROUP, create an unconstrained socket group and have s as the first member; or if g = SG_CONSTRAINED_GROUP, create a constrained socket group and have s as the first member; or if g = NULL, no group operation is performed. For an unconstrained group, any set of sockets may be grouped together as long as they are supported by a single Service Provider and are connection- oriented. A constrained socket group requires that connections on all grouped sockets be to the same host. For newly created socket groups, the new group id can be retrieved by using getsockopt() with option SO_GROUP_ID, if this connect operation completes successfully. lpSFlowspec, and iSFlowspecLen specify a block of memory containing the flow spec for socket s, if s is unidirectional and a DSTREAM type socket. Otherwise, these values are ignored. The first part of this memory block is struct FLOWSPEC, followed by any Service Provider specific data. Thus, iSFlowspecLen must be larger than or equal to the size of struct FLOWSPEC. A NULL value for lpSFlowspec indicates no application supplied flow spec. lpGFlowspec, and iGFlowspecLen specify a block of memory containing the flow spec for the socket group to be created, if (and only if) the value of parameter g is SG_CONSTRAINED_GROUP. Otherwise, these values are ignored. The first part of this memory block is struct FLOWSPEC, followed by any Service Provider specific data. Thus, iGFlowspecLen must be larger than or equal to the size of struct FLOWSPEC. A NULL value for lpGFlowspec indicates no application supplied flow spec. Similarly, a WSA version of accept is also proposed. The alert reader will note that the proposed function incorporates conditional acceptance as well as grouping. Conditional acceptance is discussed in greater detail in our proposed extension #9. The syntax is as follows: SOCKET PASCAL FAR WSAAcceptEx ( SOCKET s, struct sockaddr FAR * addr, int FAR * addrlen, FARPROC lpfnCondition ); s A descriptor identifying a socket which is listening for connections after a listen(). addr An optional pointer to a buffer which receives the address of the connecting entity, as known to the communications layer. The exact format of the addr argument is determined by the address family established when the socket was created. addrlen An optional pointer to an integer which contains the length of the address addr. lpfnCondition The procedure instance address of the application-supplied condition function which will make an accept/reject decision based on the caller information passed in as parameters, and optionally create and/or join a socket group by assigning appropriate value to the result parameter g of this function. This routine extracts the first connection on the queue of pending connections on s, and checks it against the condition function. If the condition function returns TRUE, this routine creates a new socket with the same properties as s and returns a handle to the new socket, and then optionally creates and/or joins a socket group based on the value of the result parameter g. Otherwise, reject this connection request, and proceed to the next one. If no pending connections are present on the queue, and the socket is not marked as non- blocking, WSAAcceptEx() blocks the caller until a connection is present. If the socket is marked non-blocking and no pending connections are present on the queue, WSAAcceptEx() returns an error as described below. The accepted socket may not be used to accept more connections. The original socket remains open. The prototype of the condition function is as follows: BOOL PASCAL FAR ConditionFunc( const char FAR * caller, int callerlen, GROUP FAR * g); ConditionFunc is a place holder for the application-supplied function name. The actual condition function must reside in a DLL or application module and be exported in the module definition file. You must use MakeProcInstance() to get a procedure-instance address for the callback function. The exact format of the caller parameter is determined by the address family in which the communication is occurring. The result parameter g is assigned within the condition function to indicate the following actions: if g is an existing socket group id, add s to this group, provided all the requirements set by this group are met; or if g = SG_UNCONSTRAINED_GROUP, create an unconstrained socket group and have s as the first member; or if g = SG_CONSTRAINED_GROUP, create a constrained socket group and have s as the first member; or if g = NULL, no group operation is performed. For unconstrained groups, any set of sockets may be grouped together as long as they are supported by a single Winsock Service Provider and are connection-oriented. A constrained socket group requires that connections on all grouped sockets be to the same host. For newly created socket groups, the new group id can be retrieved by using getsockopt() with option SO_GROUP_ID, if this connection operation completes successfully. The argument addr is a result parameter that is filled in with the address of the connecting entity, as known to the communications layer. The exact format of the addr parameter is determined by the address family in which the communication is occurring. The addrlen is a value-result parameter; it should initially contain the amount of space pointed to by addr; on return it will contain the actual length (in bytes) of the address returned. This call is used with connection-oriented socket types such as SOCK_STREAM. If addr and/or addrlen are equal to NULL, then no information about the remote address of the accepted socket is returned. In addition to the new connect function, we need a few new socket options: SO_GROUP_ID and SO_GROUP_PRIORITY. The group ID option is a get-only value used to discover the ID of any group that a particular socket belongs to. It is also the method used to discover the ID of a newly created group. The group priority option is used to establish (or discover) the relative priority of a socket within its group. Zero represents the highest priority. Finally, we need a way to discover which sockets belong to a particular group. To accomplish this we propose a new function: WSAEnumGroup(): The syntax is as follows: int PASCAL FAR WSAEnumGroup ( GROUP g, FARPROC lpfnCallback ); g Specifies the identifier of the socket group for which membership information is retrieved. lpfnCallback Specifies the procedure instance address of the callback function to be invoked by Winsock.DLL for each member socket in the group. Remarks This function is used to enumerate the members in the specified socket group. It uses the standard Windows enumeration procedure using a "callback" function. The callback function is called once for each member in the specified socket group. This will be repeated until either the callback function returns zero or the end of the member list has been reached. On each invocation of the callback function, a "virtual socket" descriptor will be passed in as a parameter. (For a detailed description of virtual sockets, please see WSADuplicateSocket().) The value of the virtual socket parameter must either be copied to another, non-transient SOCKET variable and retained across invocations of the callback function, or the virtual socket must be closed prior to returning. Failure to do so will result in a resource leak through lost references to virtual sockets. The prototype of the callback function is as follows: int PASCAL FAR CallbackFunc( SOCKET s ); CallbackFunc is a place holder for the application- supplied function name. The actual callback function must reside in a DLL or application module and be exported in the module definition file. You must use MakeProcInstance() to get a procedure-instance address for the callback function. The callback function must return non zero to continue enumeration; to stop enumeration, it must return zero. ???? ???? From cayman.cayman.com!wayne Thu Feb 17 19:24:01 1994 Message-Id: <9402180326.AA09470@cuba.Cayman.COM> X-Sender: wayne@cuba Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Feb 1994 22:25:33 -0500 To: martinh@jsbus.com From: "Wayne F. Tackabury" Subject: Windows Sockets v.2 Extensions X-Mailer: Status: OR The calendar on the wall is reminding me that tomorrow is the cutoff date for Winsock v.2 extensions (I also lost the piece of mail which first informed me of this...I recall you're the man to send them to). I have two in mind, but haven't had time to really develop them...perhaps if you can give me any validation as to their reasonableness (from your objective lofty vantage point :-)) or redundancy relative to already suggested, or shot down, proposed extensions. ONE would be a hosts enumeration function. I am trying to solve two problems here; one, for conventional INET family-targeted applications, is to simply allow a bulk transfer of the hosts information, independent of the underlying static or network services used to retrieve them. The other is to facilitate Winsock support for protocols which depend heavily on browsing of hierarchical names to retrieve inherently dynamic bound addresses (AppleTalk comes to mind). The trick (which I've not yet completely solved beyond the following) is to have an argument to WSAAsyncGetHostList() which would describe the hierarchy context for lookup. In the case of INET, this is an array of strings constraining a DNS zone, NIS domain, or whathaveyou; in the case of AppleTalk it represents a three level array string which would constrain or wildcard the AppleTalk NBP name, type, and zone. Hence WSAAsyncGetHostList( HWND hWnd, // Window handle for notification unsigned int wMsg, // message for notification const char far **nameContext, /* Array of string pointers describing hierarchical context for lookup, address family-specific */ char far *buf, // buffer for return info int buflen) // Buffer length, in hostent structs Return of WSAENOBUFS would return actually received number of matching hostents in lparam, allowing the application to adjust amount of buffering allocated for return. After a bunch of time with protocol-general ways of envisioning FindFirst/FindNext-style "next entry index", or dealing with the arduous AppleTalk-style "here's my list of hosts I've already heard from, only give me ones not in this list" interface semantics, I have come to the conclusion that the best, albeit less performance-friendly, way of dealing with this is to let the application worry about it. I'd be very very suprised if this proposal hasn't been raised somewhere before. TWO, I've only started thinking about in the last day or two...it would involve allowing a calling application to set the network protocol address of an interface. One could either have a straight sethostaddr() function, or tie it into a more general non-socket ioctl() function; to solve what I'm trying to solve, you don't need the latter necessarily (to set subnet address, max datagram size, etc. system wide; but then again, I'm not trying to write a generalized DHCP client). If you've used PPP, you can see the problem I'm getting at here; unless the PPP client is part of a monolithic TCP kernel, there is no way to allow server-assigned interface adddresses directly...so near as I can tell, people are forcing the issue by using bootp and rarp where they aren't really called for. This would provide common semantics for configuration of interfaces for service without providing their known addresses. Anyways, I've waxed on long enough with content of dubious originality and value...if you think there's value in pursuing this, let me know how you are planning to bring these kinds of proposals to the list, and I'll hack more complete prototypes together. Thanks, Wayne ---------------------------------- There is such a fine line between genius and stupidity. -- Nigel Tufnel, *Spinal Tap* Wayne F. Tackabury Cayman Systems, Inc. 400 Unicorn Park Dr., Woburn MA 01801 Internet: wayne@cayman.com Voice: (617) 932-1100 Fax: (617) 932-0853 CompuServe: 73207,3650 AppleLink: D0523 ???? ???? From relay1.uu.net!netmanage.com!tmima Fri Feb 18 11:51:11 1994 Message-Id: Date: Fri, 18 Feb 94 12:54:20 PST Reply-To: Tmima Koren From: Tmima Koren To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution Status: OR sethostent() gethostent() endhostent() setprotoent() getprotoent() endprotoent() setservent() getservent() endservent() ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18 13:31:23 1994 Date: Fri, 18 Feb 94 13:38:01 PST From: David B Andersen Message-ID: <940218133801_1@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock Ver 2 Status: OR Text item: Text_1 02/18/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 8. -------> IMPORTANT NOTE: <------------------- Because of limitiations in the somewhat brain-dead mailer I am using, this submittal is being broken up into two pieces. Please merge them back together when both pieces arrive. This is part 1 of 2 pieces which comprise submittal #8. Regards, David B. Andersen Intel Architecture Labs Extension #8: Quality of service specification Description: As alluded to in our proposed extension # 7, applications need a way to specify required quality of service levels (QOS) for sockets and socket groups. We feel strongly that a mechanism for specifying QOS in Winsock QOS should be compatible with corresponding work being done under the auspices of the IETF. RFC 1363 proposes a QOS specification mechanism referred to as a flow spec. We have based our proposal for how QOS should be specified at the API level on the flow spec concept. A brief overview of this concept is as follows: Flow specs describe a set of characteristics about a proposed connection-oriented, unidirectional flow through the network. An application may associate a flow spec with a socket at the time a connection request is made. This flow spec indicates parametrically what level of service is required and also stipulates how flexible the application is willing to be if the requested level of service is not available. (This ranges from "don't make a connection if I don't get all that I asked for", to "here is what I would like but I'll take anything I can get".) After a connection is established, the application may retrieve the flow spec associated with the socket and examine its contents to discover the level of service that the network is willing and/or able to provide. If the service provided is not acceptable, the application may close the socket and take whatever action is appropriate (e.g. scale back and ask for a lower quality of service, try again later, notify the user and exit, etc.) Even after a flow is established, conditions in the network may change resulting in a reduction (or increase) in the available service level. A notification mechanism is included which utilizes the existing (and proposed) Winsock notification techniques to indicate to the application that QOS levels have changed. The app should again retrieve the corresponding flow spec and examine it in order to discover what aspect of the service level has changed. Semantics: The basic QOS mechanism proposed for Winsock revolves around the flow specification (or "flow spec") as described by Craig Partridge in RFC 1361, dated September 1992. Flow specs provide a parametric representation of key QOS characteristics. Winsock's notion of a flow spec is a backwards compatible extension of that defined in RFC 1363. Applications use flow specs to indicate their service requirements, and networks use flow specs to indicate QOS availability. Flow specs divide QOS characteristics into the following general areas: 1.Network bandwidth utilization - The manner in which the application's traffic will be injected into the network. This includes specifications for average bandwidth utilization, maximum burst duration and peak burst rate. It also includes an indication which the network may provide of minimum link bandwidth (i.e. how wide the skinniest pipe is between the two hosts). 2.Sensitivity to delay - Applications indicate a delay or latency value as a target for the network, with an understanding that further reductions in delay below this value are of marginal use to the application. A means is also provided to stipulate the maximum amount of delay variation that can be tolerated. 3.Willingness to cope with data loss and service interruption - Loss properties are expressed in terms of both overall percentage of lost packets and maximum amounts of bursty loss. Service interruption indicates how long the application is willing to tolerate loss of all communication with the endpoint before considering the connection broken. 4.Level of service guarantee - Applications are able to indicate a range of requirements, from the need for an ironclad guarantee to a willingness to accept whatever is available after merely expressing a hint about QOS preferences. 5.Flow content identification - Applications may select from a wide selection of well-known constants to identify the media content of a flow. 6.Cost sensitivity - An indication of how willing the application is to minimize communications cost to the possible detriment of other QOS parameters. 7.Communications security - Applications may specify a particular encryption system or option and identify public keys to be used Flow specs are only applicable to DSTREAM style sockets which are unidirectional (either inbound or outbound). An application indicates its desire for a non-default flow spec at the time a connection request is made. Since establishing a flow spec'd connection is likely to involve cooperation and/or negotiation between intermediate routers and hosts, the results of a flow spec request cannot be determined until after the connection operation is fully completed. After this time, the application may use getsockopt() to retrieve the resulting flow spec structure so that it can determine what the network was willing and/or able to supply. Also, it is entirely possible that QOS conditions may change during the life of a connection. A means is provided, therefore, for a service provider to notify the application that it should access and inspect the current flow spec which will have one or more modified values. The Flow Spec Structure The proposed flow spec structure is defined as follows. Portions of the comment fields shown in italics indicate the corresponding flow spec field identifier as found in RFC 1363. typedef struct FlowSpec { int iMaxMsgSize; // MTU: Max message size: bytes float fAvgBw; // Token Bucket Rate: bytes/sec float fBurstLength; // Token Bucket Size: bytes float fBurstRate; // Max Trans Rate: bytes/sec float fMinLinkSpeed // Size of thinnest pipe: bytes/sec int iConnectionStatus // Status of the connection int iMinDelaySel; // Minimum Delay Noticed: float fMinDelayValue; // Delay value: usec float fMaxDelayVariation; // Max Delay Variation: usec int iLossSensitivity; // Loss Sensitivity: float fMaxLostPkts; // Max # lost MTU's over... float fLossInterval; // Loss Interval in MTU's float fMaxBurstLoss; // Burst Loss Sensitivity // max # consec. lost MTU's int iMaxSvcOutage; // Max dur for svc outage: sec int iQualOfGuarantee; // Quality of Guarantee int iFlowContent; // flow content identifier int iCostSensitivity; // Cost sensitivity int iEncryptionSel; // Selected encryption algo char far *lpEncryptionKey; // Pointer to desired key } FLOWSPEC; The sections which follow provide a detailed description of each field in the flow spec. iMaxMsgSize This field corresponds to the Maximum Transmission Unit field in RFC 1363. It describes the maximum sized message (in bytes) that the application intends to send over the flow. This must, of course, be no larger than the value of SO_MAX_DG_SIZE for the underlying service provider. The intent of expressing this value in the flow spec is not to provide a hard limit for the application. Rather, it serves two different purposes. First, it is a convenient unit for expressing loss properties. Using the default MTU of the internetwork is inappropriate since the internetwork may have a very large MTU, such as the 64 Kbytes of IP, but applications and hosts may be sensitive to losses of far less than an MTU's amount of data. For example, a voice application would be sensitive to a loss of several consecutive small packets. Secondly, the MTU also bounds the amount of time that a flow can transmit, uninterrupted, on a shared media. Similarly, the loss rates of links that suffer bit errors will vary dramatically based on the MTU size. fAvgBw This field corresponds to the Token Bucket Rate field in RFC 1363. It is one of three fields used to define how traffic will be injected into the internetwork by the sending application. As flow specs are based upon the well-known leaky bucket algorithm for flow control, this field and several others are described in terms of imaginary tokens and buckets. The token rate is the rate at which tokens (credits) are placed into an imaginary token bucket, expressed in bytes/second. For each flow, a separate bucket is maintained. To send a packet over the flow, a host must remove a number of credits equal to the size of the packet from the token bucket. If there are not enough credits, the host must wait until enough credits accumulate in the bucket. Note that the fact that the rate is expressed in terms of a token bucket rate does not mean that hosts must implement token buckets. Any traffic management scheme that yields equivalent behavior is permitted. The field indicates the number of byte credits (i.e., right to send a byte) per second which are deposited into the token bucket. The value zero is slightly special. It is used to indicate that the application is not making a request for bandwidth guarantees. If this field is zero, then the fBurstLength field must also be zero, and the type of guarantee requested may be no higher than predicted service (explained below). fBurstLength This field corresponds to the Token Bucket Size field in RFC 1363. It controls the maximum amount of data that the flow can send at the peak rate, and is expressed in terms of bytes. More formally, if the burst length is B, and the average rate is R, over any arbitrarily chosen interval T in the life of the flow, the amount of data that the flow sends cannot have exceeded B + (R * T) bytes. The imaginary token bucket is filled at the token bucket rate. The bucket size (or burst length) limits how many credits the flow may store. When the bucket is full, new credits are discarded. The field is ignored if the fAvgBw field is zero. Note that fBurstLength must be greater than or equal to iMaxMsgSize. Zero is a legal value for the field and indicates that no credits are saved. fBurstRate This field corresponds to the Maximum Transmission Rate field in RFC 1363, and is expressed in bytes/second. This rate limits how fast packets may be sent back to back from the host. Consider that if the token bucket is full, it is possible for the flow to send a series of back-to-back packets, with the length of this run equal to the size of the token bucket (fBurstLength). If the token bucket size is large, this back-to-back run may be long enough to significantly inhibit multiplexing. To limit this effect, fBurstRate bounds how fast successive packets may be placed on the network. One can think of fBurstRate as being a form of a leaky bucket. When a packet is sent, a number of credits equal to the size of the packet is placed into an empty bucket, which drains credits at the burst rate. No more packets may be sent until the bucket has emptied again. fMinLinkSpeed This field is an extension to the RFC 1363 flow spec, and is expressed in bytes/second. It is provided as a way for the network to supply useful information to the application. After a connection has been established, an application may examine this field in order to determine the capacity limitations of the underlying hops which the connection spans. All such hops will have a capacity greater than or equal to fMinLinkSpeed. A typical way for an application to use this field would be to initiate a connection requesting the lowest possible level of service. Once the connection is established, the app may then determine that higher levels of service are likely possible. It may then elect to either modify its use of the socket or perhaps trade its current socket in on one with a higher level of service. A value of zero implies that this information is not available from the network. This field is undefined for unconnected sockets. iConnectionStatus This field is an extension to the RFC 1363 flow spec. It is provided as a way for the network to indicate a change in the connection status to the application using one of the following manifest constants as values: OPERATIONAL, INTERRUPTED, or SUSPENDED. Typical scenarios might include: connection status on our cellular modem link changes to INTERRUPTED because our car just drove into a tunnel, and then changes back to OPERATIONAL when we come out the other side. Later on, connection status changes to SUSPENDED because we are going into power conservation mode. The availability of connection status may be especially useful for situations where the iMaxSvcOutage value is fairly long. A value of UNKNOWN implies that this information is not available from the network. This field is undefined for unconnected sockets. ---------- End of Part 1 ------ Continued in Part 2 --------- ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18 13:32:28 1994 Date: Fri, 18 Feb 94 13:39:08 PST From: David B Andersen Message-ID: <940218133908_3@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock Ver 2 Status: OR Text item: Text_1 02/18/94 Dear Martin, This is part 2 of 2 pieces which comprise our submittal #8. Because of limitiations in the somewhat brain-dead mailer I am using, this submittal is being broken up into two pieces. Please merge them back together when both pieces arrive. Regards, David B. Andersen Intel Architecture Labs ------------ Begin Part 2 of Submittal #8 ----------------------- iMinDelaySel and fMinDelayValue These two fields both map to the Minimum Delay Noticed field in RFC 1363. Winsock uses two fields because in the RFC the corresponding value may either be one of a set of manifest constants or a floating point number. The iMinDelaySel field is used to represent the manifest constant, and, if applicable, the fMinDelayValue field is used to store the floating point value in microseconds. The minimum delay noticed field tells the internetwork that the host and application are effectively insensitive to improvements in end-to-end delay below this value. The network is encouraged to drive the delay down to this value but need not try to improve the delay further. If expressed as a number it is the number of microseconds of delay below which the host and application do not care about improvements. Human users only care about delays in the millisecond range but some applications will be computer to computer and computers now have clock times measured in a handful of nanoseconds. For such computers, microseconds are an appreciable time. For this reason, this field measures in microseconds, even though that may seem small. Manifest constants for iMinDelaySel are as follows: NO_DELAY_SENSITIVITY -- the application is not sensitive to delay MODERATE_DELAY_SENSITIVITY -- the application is moderately delay sensitive (e.g., avoid satellite links where possible) NUMERIC_DELAY_SENSITIVITY -- the application is sensitive to delay as expressed in fMinDelayValue fMaxDelayVariation This field corresponds to the Maximum Delay Variation field in RFC 1361. It is the difference, in microseconds, between the maximum and minimum possible delay that a packet will experience. If a receiving application requires data to be delivered in the same pattern that the data was transmitted, it may be necessary for the receiving host to briefly buffer data as it is received so that the receiver can restore the old transmission pattern. (An easy example of this is a case where an application wishes to send and transmit data such as voice samples, which are generated and played at regular intervals. The regular intervals may be distorted by queuing effects in the network and the receiver may have to restore the regular spacing.) The amount of buffer space that the receiving host is willing to provide determines the amount of variation in delay permitted for individual packets within a given flow. The maximum delay variation field makes it possible to tell the network how much variation is permitted. The value of 0, meaning the receiving host will not buffer out delays, is acceptable but the receiving host must still have enough buffer space to receive a maximum transmission unit sized packet from the sending host. Note that it is expected that a value of 0 will make it unlikely that a flow can be established. iLossSensitivity, fMaxLostPkts and fLossInterval These fields together correspond to the Loss Sensitivity and Loss Interval fields in the RFC. iLossSensitivity takes on one of the following well-known values: NO_LOSS_SENSITIVITY -- The application is not sensitive to loss, relying on higher level protocols if needed. SOME_LOSS_SENSITIVITY -- The application is sensitive to loss but is not specifying a numeric requirement. Where possible, the network should choose a path with minimal loss. NUMERIC_LOSS_SENSITIVITY -- The application requires that loss characteristics be as described in fMaxLostPkts and fLossInterval. fMaxLostPkts specifies the maximum number of MTU sized packets that may be lost over an interval during which fLossInterval MTU sized packets were sent. Thus, taken together, these values specify an average loss percentage. fMaxBurstLoss This field corresponds to the Burst Loss Sensitivity field in the RFC. It states how sensitive the application's flow is to losses of consecutive packets. The field enumerates the maximum number of consecutive MTU-sized packets that may be lost. A value of zero indicates that the flow is insensitive to burst loss. Note that it is permissible to set the iLossSensitivity field to simply indicate some sensitivity to loss, and set a numerical limit on the number of consecutive packets that can be lost. iMaxSvcOutage This field represents an extension to the RFC flow spec. It indicates to the network a time interval, expressed in seconds (not microseconds), during which communications over the connection may be interrupted without considering the connection to be permanently broken. A value of zero indicates no preference on behalf of the application, and that the underlying service provider's default value should be used. iQualOfGuarantee This field corresponds to the Quality of Guarantee field in the RFC. It is expected that the internetwork will likely have to offer more than one type of guarantee. There are two unrelated issues related to guarantees. First, it may not be possible for the internetwork to make a firm guarantee. Consider a path through an internetwork in which the last hop is an Ethernet. Experience has shown (e.g., some of the IETF conferencing experiments) that an Ethernet can often give acceptable performance, but clearly the internetwork cannot guarantee that the Ethernet will not saturate at some time during a flow's lifetime. Thus it must be possible to distinguish between flows which cannot tolerate the small possibility of a failure (and thus must guaranteed at every hop in the path) and those that can tolerate islands of uncertainty. Second, it is presumed that some applications will be able to adapt to modest variations in internetwork performance and that network designers can exploit this flexibility to allow better network utilization. In this model, the internetwork would be allowed to deviate slightly from the promised flow parameters during periods of load. This class of service is called predicted service (to distinguish it from guaranteed service). The difference between predicted service and service which cannot be perfectly guaranteed (e.g., the Ethernet example mentioned above) is that the imperfect guarantee makes no statistical promises about how it might misbehave. In the worst case, the imperfect guarantee will not work at all, whereas predicted service will give slightly degraded service. Note too that predicted service assumes that the routers and links in a path all cooperate (to some degree) whereas an imperfect guarantee states that some routers or links will not cooperate. There are six legal values: NO_GUARANTEE - no guarantee is required (the host is simply expressing desired performance for the flow). IMPERFECT_GUARANTEE_REQUESTED - an imperfect guarantee is requested. PREDICTED_SVC_REQUIRED - predicted service is requested and if unavailable, then no flow should be established. PREDICTED_SVC_REQUESTED - predicted service is requested but an imperfect guarantee is acceptable. GUARANTEED_SVC_REQUIRED - guaranteed service is requested and if a firm guarantee cannot be given, then no flow should be established. GUARANTEED_SVC_REQUESTED - guaranteed service is requested and but an imperfect guarantee is acceptable. Application developers should realize that asking for predicted service or permitting an imperfect guarantee will substantially increase the chance that a flow request will be accepted. iFlowContent This field represents an extension over the flow spec defined in the RFC. The allowed values are all manifest constants which indicate the type of media being transported over the flow. Use of this field is optional. Its purpose is to provide a simplified alternative to specifying QOS parametrically. For service providers that are "tuned" to transport certain types of media, merely identifying the socket as bearing a reconginzed media type may be sufficient to identify needed QOS levels. Currently defined values include UNSPECIFIED GSM_AUDIO ADPCM_AUDIO (TBD other types of audio streams) INDEO_PRV INDEO_ISV INDEO_MRV H261 MPEG1 MPEG2 (TBD other types of video stream) SVC_PROVIDER_SPECIFIC - service providers are free to define their own constants for media streams with values greater than or equal to this. iCostSensitivity This field represents an extension over the flow spec defined in the RFC. The allowed values are manifest constants which indicate whether or not the application wishes to minimize any costs associated with a connection to the possible detriment of other QOS parameters. Allowed values are: NOT_COST_SENSITIVE - the application considers cost to be a secondary concern or no concern at all. COST_SENSITIVE - the application considers cost to be a primary concern and wishes to minimize it where possible. iEncryptionSel and lpEncryptionKey These fields represents an extension over the flow spec defined in the RFC. They are used to indicate the application's choice for encryption algorithms (if any) and also to specify a pointer to where an encryption key may be found. Interpretation of the memory contents pointed to by the encryption key pointer is service provider/encryption algorithm specific. Values for the iEncryptionSel field are also service provider specific, with the convention that zero is used to indicate that no encryption is being requested. Default Flow Spec A default flow spec is associated with each eligible socket at the time it is created. Field values for this default flow spec are indicated below. In all cases these values indicate that no particular flow characteristics are being requested from the network. Applications only need to modify values for those fields that they are interested in, but must be aware that there exists some coupling between fields as was described above. iMaxMsgSize = SO_MAX_DG_SIZE for the particular service provider fAvgBw = 0, no bandwidth request fBurstLength = 0, not applicable because fAvgBw is zero fBurstRate = 0, not applicable because fAvgBw is zero fMinLinkSpeed = supplied by network, undefined until connection occurs iConnectionStatus= supplied by network, undefined until connection occurs iMinDelaySel = NO_DELAY_SENSITIVITY fMinDelayValue = 0, not applicable fMaxDelayVariation =0, not applicable iLossSensitivity = NO_LOSS_SENSITIVITY fMaxLostPkts = 0, not applicable fLossInterval = 0, not applicable iMaxSvcOutage = 0, use provider defaults for time-out iQualOfGuarantee = NO_GUARANTEE iFlowContent = UNSPECIFIED iCostSensitivity = NOT_COST_SENSITIVE iEncryptionSel = 0, no encryption requested lpEncryptionKey = NULL The semantics for associating a flow spec with a socket or socket group appeared as part of our proposed extension #7 on socket groups. The WSAConnectEx() function which was described therein is used. For the sake of completeness, we repeat that function description here. int PASCAL FAR WSAConnectEx ( SOCKET s, const struct sockaddr FAR * name, int namelen, GROUP g, char FAR * lpSFlowspec, int iSFlowspecLen, char FAR * lpGFlowspec, int iGFlowspecLen ); s A descriptor identifying an unconnected socket. name The name of the peer to which the socket is to be connected. namelen The length of the name. g The identifier of the socket group. lpSFlowspec A pointer to the flow spec for socket s. iSFlowspecLen The length of the flow spec for socket s. It must be larger than or equal to the size of struct FLOWSPEC. lpGFlowspec A pointer to the flow spec for the socket group to be created, if the value of parameter g is SG_CONSTRAINED_GROUP. iGFlowspecLen The length of the flow spec for the socket group to be created, if the value of parameter g is SG_CONSTRAINED_GROUP. It must be larger than or equal to the size of struct FLOWSPEC. This function is used to create a connection to the specified destination. For connection- oriented sockets (e.g., type SOCK_STREAM), an active connection is initiated to the foreign host using name (an address in the name space of the socket;). When the socket call completes successfully, the socket is ready to send/receive data. For a connectionless socket (e.g., type SOCK_UNREL_DGRAM), the operation performed by WSAConnectEx() is merely to establish a default destination address which will be used on subsequent send() and recv() calls. If the socket, s, is unbound, unique values are assigned to the local association by the system, and the socket is marked as bound. Note that if the address field of the name structure is all zeroes, WSAConnectEx() will return the error WSAEADDRNOTAVAIL. Parameter g is used to indicate the appropriate actions on socket groups: if g is an existing socket group id, add s to this group, provided all the requirements set by this group are met; or if g = SG_UNCONSTRAINED_GROUP, create an unconstrained socket group and have s as the first member; or if g = SG_CONSTRAINED_GROUP, create a constrained socket group and have s as the first member; or if g = NULL, no group operation is performed. For an unconstrained group, any set of sockets may be grouped together as long as they are supported by a single Service Provider and are connection- oriented. A constrained socket group requires that connections on all grouped sockets be to the same host. For newly created socket groups, the new group id can be retrieved by using getsockopt() with option SO_GROUP_ID, if this connect operation completes successfully. lpSFlowspec, and iSFlowspecLen specify a block of memory containing the flow spec for socket s, if s is unidirectional and a DSTREAM type socket. Otherwise, these values are ignored. The first part of this memory block is struct FLOWSPEC, followed by any Service Provider specific data. Thus, iSFlowspecLen must be larger than or equal to the size of struct FLOWSPEC. A NULL value for lpSFlowspec indicates no application supplied flow spec. lpGFlowspec, and iGFlowspecLen specify a block of memory containing the flow spec for the socket group to be created, if (and only if) the value of parameter g is SG_CONSTRAINED_GROUP. Otherwise, these values are ignored. The first part of this memory block is struct FLOWSPEC, followed by any Service Provider specific data. Thus, iGFlowspecLen must be larger than or equal to the size of struct FLOWSPEC. A NULL value for lpGFlowspec indicates no application supplied flow spec. The QOS notification mechanism utilizes the existing WSAAsyncSelect() and proposed WSACallbackSelect() functions by defining an additional event: FD_QOS. If an application expresses an interest in being notified about QOS events, the service provider will utilize the available mechanisms to notify the app whenever something in the flow spec has changed. An application may access the flow spec associated with a socket or with the socket's group (if any) by retrieving the value of one of the following proposed get-only socket options: SO_FLOWSPEC or SO_GROUP_FLOWSPEC. A returned value of NULL indicates that there is no associated flow spec. ------------- End of Submittal #8 ----------------------------- ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18 13:32:51 1994 Date: Fri, 18 Feb 94 13:39:17 PST From: David B Andersen Message-ID: <940218133917_5@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock Ver 2 Status: OR Text item: Text_1 02/18/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 9. For each of our proposals we supply a desciption of the proposed extension, our motivations for making the extension proposal, and the detailed syntax for how the extension might be implemented. We would also like to volunteer our services to assist in the process of collating and summarizing the various submitals that are coming in from Forum members. Please let us know how we can best assist you in this process. Regards, David B. Andersen Intel Architecture Labs Extension #9: Conditional acceptance of socket connection requests Description: The current Winsock specification does not provide a way for an application with a listening socket to conditionally accept an incoming connection request based upon the requester's address. (In other words, Winsock has no equivalence to caller ID.) This is curious since the current Winsock spec includes an error code for the connect() function which indicates that the connection attempt was rejected, but does not provide a mechanism that allows a listening application to cause this rejection to occur. Currently, the only viable option is for the listening app to accept the connection, use getpeername() to establish the caller's ID and then immediately close the socket. The caller may well begin sending as soon as the connection is accepted, and will probably not understand why the connection was suddenly closed. We propose to remedy this by making it possible for an application to discover who is wanting to connect prior to accepting the request, and by allowing the app to reject the request if it decides to. Motivation: Most other transport level interfaces have such a feature. It's usefulness is, I think, obvious. Semantics: In our proposed extension #7 on socket groups we introduced the proposed WSAAcceptEx() function as a means to performing grouping of sockets. This same function is also used for conditional acceptance. The basic approach is to allow the app to specify a conditional acceptance function that is called incident to the invocation of WSAAcceptEx(). The inbound parameter identifies the address of the requester. The return value indicates whether the connection is to be accepted or rejected. As noted previously, the application may also utilize this function to establish the new socket as a group member. We repeat the syntax for the WSAAcceptEx() function below: SOCKET PASCAL FAR WSAAcceptEx ( SOCKET s, struct sockaddr FAR * addr, int FAR * addrlen, FARPROC lpfnCondition ); s A descriptor identifying a socket which is listening for connections after a listen(). addr An optional pointer to a buffer which receives the address of the connecting entity, as known to the communications layer. The exact format of the addr argument is determined by the address family established when the socket was created. addrlen An optional pointer to an integer which contains the length of the address addr. lpfnCondition The procedure instance address of the application-supplied condition function which will make an accept/reject decision based on the caller information passed in as parameters, and optionally create and/or join a socket group by assigning appropriate value to the result parameter g of this function. This routine extracts the first connection on the queue of pending connections on s, and checks it against the condition function. If the condition function returns TRUE, this routine creates a new socket with the same properties as s and returns a handle to the new socket, and then optionally creates and/or joins a socket group based on the value of the result parameter g. Otherwise, reject this connection request, and proceed to the next one. If no pending connections are present on the queue, and the socket is not marked as non- blocking, WSAAcceptEx() blocks the caller until a connection is present. If the socket is marked non-blocking and no pending connections are present on the queue, WSAAcceptEx() returns an error as described below. The accepted socket may not be used to accept more connections. The original socket remains open. The prototype of the condition function is as follows: BOOL PASCAL FAR ConditionFunc( const char FAR * caller, int callerlen, GROUP FAR * g); ConditionFunc is a place holder for the application-supplied function name. The actual condition function must reside in a DLL or application module and be exported in the module definition file. You must use MakeProcInstance() to get a procedure-instance address for the callback function. The exact format of the caller parameter is determined by the address family in which the communication is occurring. The result parameter g is assigned within the condition function to indicate the following actions: if g is an existing socket group id, add s to this group, provided all the requirements set by this group are met; or if g = SG_UNCONSTRAINED_GROUP, create an unconstrained socket group and have s as the first member; or if g = SG_CONSTRAINED_GROUP, create a constrained socket group and have s as the first member; or if g = NULL, no group operation is performed. For unconstrained groups, any set of sockets may be grouped together as long as they are supported by a single Winsock Service Provider and are connection-oriented. A constrained socket group requires that connections on all grouped sockets be to the same host. For newly created socket groups, the new group id can be retrieved by using getsockopt() with option SO_GROUP_ID, if this connection operation completes successfully. The argument addr is a result parameter that is filled in with the address of the connecting entity, as known to the communications layer. The exact format of the addr parameter is determined by the address family in which the communication is occurring. The addrlen is a value-result parameter; it should initially contain the amount of space pointed to by addr; on return it will contain the actual length (in bytes) of the address returned. This call is used with connection-oriented socket types such as SOCK_STREAM. If addr and/or addrlen are equal to NULL, then no information about the remote address of the accepted socket is returned. ???? ???? From ormail.intel.com!intelhf.intel.com!ccm!david_b_andersen Fri Feb 18 13:55:06 1994 Date: Fri, 18 Feb 94 13:45:15 PST From: David B Andersen Message-ID: <940218134515_7@ccm.hf.intel.com> To: martinh@jsbus.com cc: Charlie_Tai@ccm.hf.intel.com, JAWADK@MICROSOFT.COM Subject: Input for Winsock Ver 2 Status: OR Text item: Text_1 02/18/94 Dear Martin, Intel is pleased to supply the following input to the Winsock 2 definition process. There are 10 proposals in all, with this submittal corresponding to proposal number 10. (Finally!) Regards, David B. Andersen Intel Architecture Labs Extension #10: Integration hooks for Windows Telephony Description: One of the primary benefits in extending Winsock to cover multiple transports will be in providing a uniform and consistent way to access to the data transport capabilities of telephony connections, particularly high-bandwidth, digital telephony. In order to achieve this we believe it is essential that Winsock work smoothly with the Windows Telephony API (TAPI). As both APIs are built upon the Windows Open Systems Architecture (WOSA) foundation, we assume at the outset that the best interworking will be achieved when a single driver acts simultaneously as both a Winsock and TAPI service provider. There are several capabilities which are key to facilitating this close interworking between call control and data transmission. Foremost among these is the ability for applications to utilize telephony networks without needing to be explicitly aware that they are doing so. Winsock should be able to accommodate this by providing a uniform data transport abstraction that is common and consistent across all supported networks. Winsock service providers should implement for telephony networks the multiplexing capability that is expected and required on packet switched networks. Secondly, a method is needed to transition back and forth between controlling a call with TAPI and transmitting data with Winsock. These capabilities can be expressed by adding two additional socket options for accessing underlying TAPI-specific identifiers. Motivation: Ever since the earliest days of SLIP and on into the present with PPP, there has never been a standardized way to establish an underlying telephone call. When a protocol such as TCP/IP or NetBIOS is to be run over a telephony connection, the native addressing format of the protocol has no way to include the required phone number. In these instances, the application will frequently need to establish the connection itself prior to initiating data communications. The proper interface to use for this is TAPI, since that is what it was made for. Other protocols are designed specifically for telephony connections and their notion of address includes the phone number. When using such a protocol, the application need not be concerned with pre-establishing the telephony connection, as the service provider will have all of the information needed to establish the connection itself. However, even under these circumstances, we don't want to preclude the application from being able to exercise control over the underlying call. Thus providing a way to go from a Winsock data connection to the underlying TAPI call and back again would be both powerful and useful. Semantics: Creating Winsock Sockets on an Existing Call TAPI contains a function lineGetID that, given a line, address, or call allows the app to find the companion service-specific device name corresponding with the call. For example, lineGetID can be invoked on an existing TAPI call (using its handle) requesting the Winsock "device name" corresponding to the given call. If the TAPI provider does not support Winsock , an error is returned. Otherwise, a Winsock "device name" is returned. #include "tapi.h" LPVARSTRING lpDeviceID; HCALL hCall; int Size_of_POTS; Size_of_POTS = sizeof(int) + sizeof(POTS_Address); lpDeviceID = Any-Memory-Allocation-Function ( sizeof(VARSTRING) + Size_of_POTS ); lpDeviceID->dwTotalSize = sizeof(VARSTRING) + Size_of_POTS; lineGetID( 0, 0, hCall, LINECALLSELECT_CALL,lpDeviceID, "Winsock"); What is actually returned in the VARSTRING struct pointed to by the lpDeviceId parameter is the information that an application using Winsock would need to create one or more sockets over an existing phone call: namely a valid Winsock address family and the remote address itself. With this information, the application can create a socket of the desired type and request that a connection be established. #include "Winsock.h" SOCKET s; void FAR * lpDest_address; lpDest_address = lpDeviceID + lpDeviceID->dwStringOffset; s = socket( (int)*lpDest_address, SOCK_UNREL_ISOCH_STREAM, 0 ); connect( s, lpDest_address, &Size_of_POTS ); // Now, you can use Winsock as appropriate. The underlying service provider will realize that a new call does not need to be placed and simply create the required data stream. Transitioning a Call From Winsock to TAPI In transitioning from a data transmission mode to a call control mode, the application is strongly advised to first use shutdown() to gracefully terminate the existing data traffic without causing the underlying resources (i.e. the phone call) to be released. Once this is done the application can retrieve the values of PVD_CALL_ID which is a "Call ID" assigned by the Service Provider (SP) corresponding to the underlying call, and TAPI_DEVICE_ID which is a TAPI device ID for the line over which the call was placed. Having obtained the information, the application is then ready to invoke appropriate TAPI functions in order to find the appropriate call handle as follows and manipulate the call thereafter. #include "Winsock.h" #include "tapi.h" SOCKET s; DWORD dwCallID; // Call ID defined by SP DWORD dwDeviceID; // TAPI line device ID LPHLINEAPI lphLineApp; LPHLINE lphLine; LPLINECALLLIST lpCallList; // A connection associated with socket s has been set up, // and some data may have been transferred over it using // Winsock. Now, we would like to retrieve and manipulate the // underlying TAPI call. shutdown( s, SD_BOTH ); getsockopt( s, SOL_PROVIDER, PVD_CALL_ID, &dwCallID, &sizeof(DWORD)); getsockopt( s, SOL_PROVIDER, TAPI_DEVICE_ID, &dwDeviceID, &sizeof(DWORD)); lineInitialize(lphLineApp, ... ); lineOpen(*lphLineApp, dwDeviceID, lphLine, ... ); // Here, allocate appropriate memory for the Call List // pointed to by lpCallList. lineGetNewCalls(*lphLine, 0, LINECALLSELECT_LINE, lpCallList); // Search for the list to find the matching hCall which has // the same "Call ID" (obtained by using lineGetID() with // "WINSOCK" device class, as shown above) as the dwCallID // returned from getsockopt() earlier. // Now, you can use TAPI to manipulate hCall as appropriate. Transitioning a Call Back to Winsock from TAPI If the application wishes to resume data communications on a call that has been manipulated with TAPI, it is advisable to assume that all existing sockets in the shutdown state are, in some sense, broken. Therefore, the application should first use socket() to create replacement sockets, and then use closesocket() to eliminate all sockets that were left in the shutdown state. Eliminating all of the old sockets first is not wise as this will likely cause the underlying phone call to be dropped. #include "Winsock.h" SOCKET old_s, new_s; VOID FAR * name; int FAR * namelen; new_s = socket( AF_POTS, SOCK_UNREL_ISOCH_STREAM, 0 ); getsockname( old_s, name, namelen ); closesocket( old_s ); bind( new_s, name, namelen); // Now, use lineGetID() to get the (maybe new) destination // address, and reconnect using connect() as shown above ???? ------------------------------------------------------------------------- Martin Hall 108 Whispering Pines Drive, Suite 115 JSB Corporation Scotts Valley, California 95066 martinh@jsbus.com Tel: 408-438-8300 Fax: 408-438-8360 From: rcq To: martinh Cc: towfiq; davidtr Subject: Windows Sockets 2 Contribution Date: Sunday, March 06, 1994 7:22PM Return-Path: Date: Sun, 6 Mar 94 19:22:35 EST Message-Id: <9403070022.AA18034@mailserv-D.ftp.com> To: martinh@jsbus.com Subject: Windows Sockets 2 Contribution From: netmail!rcq@ftp.com (Bob Quinn) Reply-To: netmail!rcq@ftp.com Cc: towfiq@sunsite.unc.edu, davidtr@microsoft.com Sender: netmail!rcq@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Sun Mar 6 19:22:11 1994] Originating-Client: aeolus.ftp.com Content-Length: 17903 ------------------------------------------------------------------------------ Gentlemen: I apologize for this very late entry. Unfortunately, the delay couldn't be avoided. I hope these suggestions can still be considered. I have forwarded this one file with all my suggestions to all three of you. And I forwarded individual messages for each of these items to Martin, as he requested in his original solicitation. Thanks for your consideration, -- Bob Quinn rcq@ftp.com FTP Software, Inc. No. Andover, MA Version 2.0 Windows Sockets suggested improvements -------------------------------------------------- The following file contains numbered suggestions for Version 2.0 of the Windows Sockets specification in the format requested by Martin Hall (e.g. one line summary, followed by a single paragraph description). The order in which they appear is arbitrary (i.e. NOT related to their priority). -- (1)Summary: Allow optional support of Windows Sockets extensions and add a new function to return bit flags to indicate which optional features a WinSock implementation supports. Description: The Windows Sockets API should use The Hosts Requirements RFC 1122 as a model for differentiating between required and optional features. Since it is an API, not a protocol specification, the WinSock spec can go one step further to provide a mechanism for reporting on the optional features supported (e.g. a function GetWinsockExtensions() that returns a pointer to bitflags defined by the Windows Sockets specification to denote different extensions). -- (2) Summary: Add ability to support larger IP address space as needed by Simple Internet Protocol (IPng contender). Description: SIPP is one of the contenders the IETF is considering for IP "Next Generation" (IPng). "In order to implement the Simple Internet Protocol (SIPP) [Deering, ietf-draft, Nov'92] in an operating system based on 4.x BSD, changes must be made to some of the application program interfaces (APIs)...This paper presents a first attempt to define the API changes needed to support SIPP in BSD systems." The primary change the API must deal with is an increase in the size of an IP address from 4-bytes to 8-bytes. from SIPP API Specification (draft-ietf-sip-bsd-api-01.txt) 12/20/93 by Richard E. Gilligan (bob.gilligan@eng.sun.com) Summary of new additions: ------------------------- /* Simple Internet Protocol Address Form in use (NOT a socket type) */ #define AF_SIPP 24 /* If AF_SIFF, sockaddr_in fields are redefined by macros */ #define sipp_addr sin_zero #define sipp_zero sin_addr /* sockets passed between processes use setsockopt() to set addr form */ #define SIPP_ADDRFORM 0x16 /* setsockopt() to set flow ID in SIPP packets sent (cannot getsockopt() on received SIPP packets, however) */ #define SIPP_FLOWID 0x15 /* new gethostbyname() equivalent for SIPP addresses */ struct hostent *hostname2addr(const char *name, int af, char *buf, int buflen); /* new ascii2addr() and addr2ascii() for SIPP address input/output */ int ascii2addr(long af, char *cp, char *ap); char *addr2ascii(long af, char *ap, char *buf, int buflen); -- (3) Summary: Allow retrieval of local IP address without using name resolution. Description: Allow support for the BSD gethostid() function, as well as the SIOCGIFADDR option for the ioctlsocket() function. For multi-homed stacks, SIOCSIFADDR should also be allowed (to set local IP address). -- (4) Summary: Provide access to the broadcast address. Description: Define support for the ioctlsocket() options SIOCGIFBRDADDR and SIOCSIFBRDADDR to get and set the IP Broadcast address. -- (5) Summary: Provide the Address Resolution Protocol (ARP) table. Description: Allow support for the SIOCGARP, SIOCSARP and SIOCDARP ioctlsocket() options to get, set and delete entries in the TCP/IP protocol stack's ARP table. -- (6) Summary: Allow all low-level interface ioctlsocket() options to provide full control to an application on multi-homed hosts. Description: The following ioctlsocket() options should be (optionally) supported: - SIOCGIFADDR and SIOCSIFADDR ioctlsocket() options to get and set the interface address. - SIOCGIFDSTADDR and SIOCSIFDSTADDR to get and set point-to-point interface address. - SIOCGIFFLAGS and SIOCSIFFLAGS to get and set interface flags (which indicate, for example, if the interface is point-to-point, supports broadcast addressing, whether the interface is running... - SIOCGIFCONF to get the interface configuration list containing one ifreq structure (a la BSD) for every interface available. - SIOCGIFMETRIC and SIOCSIFMETRIC to get and set the routing metrics (the kernel routing tables). -- (7) Summary: Allow direct manipulation of the TCP Window. Description: Define (optional) support of the following: - SIOCGHIWAT and SIOCSHIWAT ioctlsocket() options to get and set the TCP Window High Water mark. - SIOCGLOWAT and SIOCSLOWAT ioctlsocket() options to get and set the TCP Window Low Water mark. - SO_RCVLOWAT and SO_SNDLOWAT setsockopt() options to get and set the send and recieve low water marks. -- (8) Summary: Define support for multicast using explicit binding (with the bind() function). Description: Any UDP Socket can send a datagram to a multicast address, but to receive a multicast packet the socket must be (explicitly) bound to the multicast address. The underlying stack should do the right thing to register the multicast address (e.g. using IGMP according to Hosts Requirements RFC1122). -- (9) Summary: Define a mechanism that would optionally prevent re- entrant messages to an application while a function (blocking or non-blocking) is pending. Description: Currently there is no blocking hook strategy that will prevent reentrant messages to a calling application and work with all Windows Sockets implementations available. Since there are many applications and DLLs in existence that need network access but cannot be rewritten to handle reentrant messages, a caller should not be required to handle re-entrant messages while a network operation is pending. A blocking hook function that prevents reentrant messages should be possible on all WinSock DLL implementations. -- (10) Summary: As long as every process registers with a Winsock DLL, it should be able to access the sockets of another process. Description: Optional socket sharing between tasks can be implemented in one of two ways: explicit or implicit. Implicit sharing would allow any taskt that calls WSAStartup() to to use any socket available. Explicit sharing (as in OS/2) would require a task to call ExportSocket(s) to make a socket sharable and any task that wanted to use exported sockets would need to call ImportSocket(). Either method is sufficient and necessary to facilitate creation of many intermediate API's ("middleware") and master server applications (that spawn other server applications, e.g. inetd). In addition, this new socket sharing ability will require new function definitions to provide information on a per socket basis. Specifically: - WSAGetLastSocketError() to get the last error for an individual socket (whereas WSAGetLastError() is task-based). - WSAIsSocketBlocking() to determine if an individual socket has a blocking operation pending. - WSACancelSocketBlocking() to cancel an individual blocking socket. Another possible strategy might be to leave the current two functions and add a setsockopt() option to select a particular socket for these functions to report on. The task that creates a socket "owns" the socket. When that task calls WSACleanup() the WinSock DLL should destroy the socket, whether or not the application called closesocket(). Subsequent calls by other tasks that reference that socket should fail with WSAENOTSOCK. -- (11) Summary: Action of the WinSock DLL and underlying stack after a non-blocking closesocket() call needs clarification. Description: When an application calls closesocket() with a non-blocking socket: - a WinSock DLL should also fail with WSAEWOULDBLOCK on a non- blocking socket without SO_LINGER set (currently the specification only says it should with a non-zero SO_LINGER setting) - the specification should determine a default timeout for closing a socket (e.g. a default time period after which the WinSock DLL or underlying stack assumes the other end is not going to respond to the TCP , sends a and releases resources. - the specification should also specify whether an application should call closesocket() a second time after it returns a WSAEWOULDBLOCK error, or use some other means to determine the state of the socket (e.g. select() or asynch message). - the specification should determine whether an application should call WSACleanup() immediately upon return from a closesocket() call that fails with WSACleanup, and describe the action of WSACleanup() when this happens (i.e. reset the connection). -- (12) Summary: Define standard database format, locations, and mechanisms for finding and setting them. Description: WinSock DLLs should have their (standard BSD format) database files in a well-known location, there should be a mechanism for locating them (e.g. getservent(), gethostent(), getprotoent() functions) and setting them (setservent(), sethostent(), setprotoent() functions). This would have the added benefit of allowing sequential search of the file(s) by an application (creating a function to do so is unnecessary). -- (13) Summary: Define the C++ Class Library for Windows Sockets Description: The Windows Sockets API should have a standard class library defined that takes advantages of OOP encapsulation features with some specialized classes that make programming to the specification easier (e.g. TCP server, TCP client, etcetera). -- (14) Summmary: Define the standard Error Text for WinSock errors Description: Use the BSD 4.3 descriptions for analogous errors in English. Provide the source code for one possible function that uses string resources to translate error numbers into text, but put the onus on the applica- tion developer to implement the function and provide the text (so they can translate into other languages if they want to). -- (15) Summary: Statements needed on some issues Description: The specification should make statements to clarify the assumptions an application developer can make in regards to: - assuming a socket is equivalent to a file descriptor - socket sharing between processes - database file (host table, protocol and services file) format and location - name resolution protocols used - support of the Unix Domain, the loopback addresses, and recommendations for local interprocess communication in Windows - recommended ways to retrieve local username. - caution application developers not to do more than one recv() call in their FD_READ message handler (a common mistake). -- (16) Summary: Define support for protocols other than TCP/IP Description: At a minimum, describe support for NetBEUI, IPX/SPX and Appletalk. -- (17) Summary: Define a standard debugging paradigm Description: Current support of setsockopt(SO_DEBUG) option is spotty at best, and undefined (so it differs between winsock implementations). The specification should make recommendations on the mechanism to use for output and the format of the output. The Windows Debug device is an obvious candidate, though it is very crude since it doesn't provide a means of filtering output and can be overloaded. Defining a DDE or OLE interface would be more elegant and useful. -- (18) Summary: Define a mechanism for handling multiple Winsock DLL's simultaneously. Description: With the support of protocol suites in addition to TCP/IP, users are likely to need more than one WinSock DLL in use simultaneously. The Windows Sockets specification must define a mechanism for multiplexing co-resident Windows Sockets API's. Microsoft's Service Provider Interface (SPI) seems a likely candidate. -- (19) Summary: Define a standard mechanism for determining the version of the WinSock DLL implementation itself Description: Require the use of the standard Version Resource or add a field to WSAData so a program can retrieve a numeric version description in a standard way. -- (20) Summary: Define a mechanism to allow access to the subnet mask. Description: Define the use of the ioctlsocket() options SIOCGIFNETMASK and SIOCSIFNETMASK to get and set the IP subnet address mask. -- (21) Summary: Provide a mechanism to allow access to the IP routing. Description: Define the use of the ioctlsocket() options SIOCADDRT and SIODELRT to add and delete an IP route. -- (22) Summary: Provide for asymmetric send and receive Maximum UDP datagram sizes. Description: Currently there is only one iMaxUdpDg (maximum UDP Datagram size) in the WSAData structure returned by WSAStartup(). Since outgoing datagrams do not make large buffer demands, but incoming oversized datagrams do, some TCP/IP protocol stacks can send oversized Datagrams but cannot receive them. Just as there is symmetry with send and receive buffer sizes (SO_SEND and SO_RECV options for setsockopt), there should be symmetry for iMaxUdpDg to differentiate the max UDP datagram sizes that an application can send and receive. -- (23) Summary: Provide a mechanism to set the Time-to-Live field in an IP packet. Description: In BSD the only way to get at the IP Time-To-Live (TTL) field is to request a SOCK_RAW socket for IPPROTO_IP, and create the IP header in it's entirety. Since many TCP/IP stacks cannot provide this service and because it invites disaster, this is not ideal. Setting the TTL is very useful for providing a simple mechanism to do the typical (UDP or ICMP) traceroute function. The spec should define a simple mechanism such as a SO_TTL option for setsockopt() that would allow setting the TTL without wreaking havoc. -- (24) Summary: Provide a mechanism to get a "privileged port" Description: Provide the function rresvport(), to return a port number between 512 and 1024. -- (25) Summary: Provide API support for gather reads and scatter writes. Description: Provide (equivalents for) the functions readv() and writev(). -- (26) Summary: Provide a symmetrical function to gethostname() to allow setting a local hostname. Description: Define a new function sethostname(). -- (27) Summary: Define a mechanism to retrieve network statistics Description: There are many times when an application needs access to network stack statistics (such as when implementing an network management station, for example). There should be a function that provide statistics akin to those returned by BSD netstat. This function could return a pointer to a network domain specific statistics structure that had counts of protocol packets in/out, error counts, etcetera. -- (28) Summary: Define how the Windows Sockets API expects the TCP/IP stack to implement out of band data (urgent data). Description: Describe the fact that OOB data is *not* truly "out of band" (i.e. that it cannot be retrieved until all data previous to it has been processed). The reason for this limitation is that a TCP urgent pointer can point ahead to data that the stack hasn't received yet. The specification should provide the semantics --preferably as an example--of how OOB should be used when "in-line" and not. -- (29) Summary: Each function should have a simple sample to show how to use it. Description: A sample is worth a thousand words. Many functions warrant more than one example to show the different ways to use a them, but the samples don't need to cover all possible variations (just some of the common ones, and particularly those that cause confusion). -- (30) Summary: Provide a mechanism for setting the TCP push bit. Description: Add an option flag for send() that allows setting the TCP push bit since some TCP/IP stacks require receipt of a TCP segment with the push bit set before data will be made available to the application. Another possibility is to adopt the flush() function used in BSD. NOTE: This is not related to the TCP_NODELAY setsockopt() option which overrides the Nagle algorithm. -- (31) Summary: Add an option to turn off UDP checksumming Description: Many new applications are doing transmission of multi-media (e.g. video and audio) and typically they use UDP. Some applications may be tolerant of errors in the data received and might prefer to receive damaged data over the alternative of not receiving the data at all. Adding a setsockopt() option to disable UDP checksumming (which is optional as per The hosts requirements RFC1122), would allow this possibility. -- (32) Summary: When an FD_READ message contains an error, don't require the application to call the notification reenabling function (recv() or recvfrom()). Description: One very common error in Windows Sockets application programming is not to call recv() or recvfrom() when an error is passed in an FD_READ message. Subsequently, the WinSock DLL will not send anymore FD_READ messages, though there may in fact be data pending. Since errors are infrequent, it should not cause problems if the FD_READ event is "edge triggered" for messages containing errors. In other words, after a WinSock DLL sends an FD_READ message containing an error, it should post subsequent FD_READ messages even if the application hasn't called either recv() or recvfrom() (the "notification re-enabling functions"). -- (33) Summary: SOCK_RAW useage should be defined. Description: At a minimum, the use of SOCK_RAW for IPPROTO_ICMP should be defined.