From martinh@jsbus.com Wed Apr 20 02:14:13 1994 Received: from jsbus.jsbus.com (jsbus.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20754; Wed, 20 Apr 1994 12:15:08 -0400 Received: by jsbus.jsbus.com id aa12214; 20 Apr 94 9:15 PDT From: Martin Hall To: winsock-hackers@sunsite.unc.edu, winsock-users@sunsite.unc.edu Subject: *** WinSock 2 Announcement *** X-Mailer: SCO Portfolio 2.0 Date: Wed, 20 Apr 1994 9:14:13 -0700 (PDT) Message-Id: <9404200914.aa12138@jsbus.jsbus.com> This is a little later than we'd intended because of various things we've wanted to finalize... Here's important data for all of you interested in the NEXT version of Windows Sockets. Please note we've worked hard to try and incorporate all suggestions and experience into this. If you have ideas or requests, it doesn't mean you've lost your chance. On the contrary, your participation is encouraged. Please note, however, that we don't want to start email discussion of the following until AFTER the Interop meeting. Following that meeting we will publish details of that meeting and any refinements to the following. THEN we will get into the real technical discussions. So please hold of with WinSock 2 email until then. thanks everyone Martin (on behalf of Martin, Dave & Mark) --------------------------------------------- Windows Sockets Version 2 - Kick Off Details --------------------------------------------- Date: April 18, 1994 Authors: Martin Hall, Dave Treadwell, Mark Towfiq This document is organized as follows 1. Objectives (Why are we doing this?) 2. Overview (What's it all about?) 3. Organizational Framework 3.1 Moderators 3.2 Review Boards 3.2.1 Application Review Board 3.2.2 Transport Review Board 3.3 Design/Functionality Groups 3.3.1 Generic API Extensions & Additions 3.3.2 Specification Clarifications 3.3.3 Name Resolution 3.3.4 Operating Framework 3.3.5 TCP/IP 3.3.6 IPX/SPX 3.3.7 Appletalk 3.3.8 Telephony 3.3.9 OSI 4. Timeframes 5. Discussion Forums 6. Key Dates 7. Actions Required -------------------------------------- 1. Objectives (Why are we doing this?) -------------------------------------- Windows Sockets has succeeded to date because 1. It has met the needs of application developers ("I'm tired of all these different API's!") 2. It has led to easier decisions for end users ("I want a WinSock app, I want a WinSock compliant stack and I want them now!") 3. It's been fun and pursued in a great spirit of cooperation The burgeoning implementation of LAN environments, the rise and rise of TCP/IP, the widespread acceptance of Windows Sockets in the application developer community and amongst application users have all helped make Windows Sockets something of a de facto standard in a very short period of time. It is therefore natural to consider amending and extending Windows Sockets to make it the de facto transport API for all data communication irrespective of protocol. ---------------------------------- 2. Overview (What's it all about?) ---------------------------------- The Windows Sockets Version 2 specification will extend Windows Sockets Version 1.1 in 3 key areas 1. API Extensions Over 2 years experience of Windows Sockets has led to various suggestions for improvements to the existing specification. There are a number of proposals for API additions and extensions which make it even easier for application developers to utilize Windows Sockets implementations. Some of these extensions are likely to be generically applicable, some will be transport specific. 2. Multiple Network Transport Capabilities The success of version 1.1 of Windows Sockets has led to a clamour for support of network transports other than TCP/IP. Requests have been made to design support for IPX/SPX and AppleTalk specifically. In response to demand for a standard data transfer API for emerging technology such as ATM and telephony-based transports, there will also be consideration of how best to enable this in a Windows Sockets framework. The design groups in Windows Sockets 2 will also seek to create a generic architectural framework that will host any network transport. 3. Operating System Considerations & Architectural Issues The Microsoft Windows Operating System platforms will soon be extended beyond Windows 3.1 and Windows NT for which Windows Sockets 1.1 was designed. Windows Sockets Version 2 will take into account not just these platforms but forthcoming versions of both Windows NT and Chicago. An important goal of WinSock 2 is thus ensuring that WinSock applications can be well-integrated within these operating systems. --------------------------- 3. Organizational Framework --------------------------- The success of Windows Sockets 1.1, the complexity and breadth of issues under discussion for Windows Sockets version 2 and the number of people now involved in the various Windows Sockets forums means we need a little clearer operational structure for progress this time around. In order to allow everyone to contribute to areas which they care about we have designed the following operational structure to facilitate discussion and to enable maximum progress. The most important groups are the Review Boards and Functionality/Design Groups. Together, these groups will be responsible for discussing, designing and agreeing on the practicality of new functionality. -------------- 3.1 Moderators -------------- Martin Hall, Dave Treadwell and Mark Towfiq will act largely as coordinators. ------------------ 3.2 Review Boards ------------------ The reason for establishing Review Boards is to enable the ongoing pragmatic goals of Windows Sockets to be realized. In the world of Windows Sockets, pragmatism is defined by 1. The applicability of Windows Sockets functionality to application developers. 2. The ease with which functionality can be implemented by Windows Sockets providers (typically, but not necessarily, network transport vendors) To this end, we would like to set up 2 review boards. Each board will review submissions from each Functionality Group in the light of the pragmatic goals of Windows Sockets. 3.2.1 Application Review Board ------------------------------- Charter: The Application Review Board will review submissions from each Functionality Group. It will focus on the submission's applicability to and ease of use by application developers as well as confirming that functionality required by applications is supported. Membership: A maximum of one representative from each company will contribute to this group. 3.2.2 Transport Review Board ----------------------------- Charter: The Transport Review Board will review submissions from each Functionality Group. It will focus on the ease of implementation of a piece of functionality. Membership: A maximum of one representative from each company will contribute to this group. 3.3 Design/Functionality Groups ------------------------------- The reason for establishing Design/Functionality Groups is to break up the large body of issues that require discussion for WinSock 2 into manageable chunks. The following groups will also allow people to focus on areas of particular interest and ignore ones they don't care about. 3.3.1 Generic API Extensions & Additions ----------------------------------------- Charter: To design and specify general extensions to the Windows Sockets API. Features and changes should be applicable to multiple transport protocols. Proposals: Improved support for other languages: C++, Basic, Pascal True asynchronous send() and recv() mechanisms Ability to share sockets between tasks/processes "Deferred accept()"--don't establish connection immediately SO_SNDTIMEO and SO_RCVTIMEO socket options 4-byte per-socket context value stored by winsock DLL Standard routine to map winsock error codes to strings Aplication yielding, blocking hooks Socket Groups Support for message-oriented (partial) receives Per-socket query of max message length Support for connect and disconnect data Transaction-oriented transport support Mechanism for querying optional functionality Scatter write, gather read sethostname() Mechanism to retrieve network statistics 3.3.2 Specification Clarifications ----------------------------------- Charter: Resolve ambiguities in the Windows Sockets specification to ensure that all Windows Sockets implementations have a consistent interpretation of the interface. Proposals: WSAAsyncSelect() issues Multiple versions supported by a single winsock DLL Unconnecting datagram sockets FD_CLR performance improvements s_port in servent struct is int Stack space requirements on winsock DLL NULL array pointers in hostent struct Structure packing of servent, protoent winsock.h: all ports, ip addrs in NETWORK order closesocket() on nonblocking sockets Samples for every API FD_READ contains error--> no need for recv() 3.3.3 Name Resolution ---------------------- Charter: Design and specify a name-service independent interface which allows Windows Sockets applicationt to resolve huiman-readable host or service names into Windows Sockets transport addresses (SOCKADDRs). Proposals: Support for other name service providers Host/Service enumeration Internationalizable (unicode) name resolution routines Dynamic service registration Directory Service support Define standard location for database files 3.3.4 Operating Framework -------------------------- Charter: Ensure that Windows Sockets DLLs and transport protocols can coexist in the various operating systems which support Windows Sockets. Proposals: Operating System versions--Win 3.1, WFW, NT, Chicago Configuration Architecture Multiple Transport Procotol Stacks on a single host Multiple Windows Sockets DLLs on a single host Clearinghouse for address familys, protoocls, socket types Mechanism for determining version of winsock DLL 3.3.5 TCP/IP ------------- Charter: Provide TCP/IP-specific extensions to the Windows Sockets API. Proposals: ICMP, Raw Sockets, Ping RFC 793 & 1122 OOB Data support Get/Set/Delete ARP entries gethostid() SIOCGIFADDR, SIOCGARP, SIOCGHIWAT, SIOCGIFNETMASK, SIOCADDRT, etc. Mechanism to set TTL in IP header rresvport() IP multicast support (IGMP) IPng support UDP datagram send size != receive size Standardize OOB handling Option to disable UDP checksum 3.3.6 IPX/SPX -------------- Charter: Provide IPX/SPX-specific extensions to the Windows Sockets API. Proposals: No specific ones as yet 3.3.7 AppleTalk ---------------- Charter: Provide AppleTalk-specific extensions to the Windows Sockets API. Proposals: No specific ones as yet 3.3.8 Telephony ---------------- Charter: Extend Windows Sockets to handle telephony applications including atm, isdn, etc. Proposals: Lots of interest 3.3.9 OSI ---------------- Charter: Provide OSI-specific extensions to the Windows Sockets API. Proposals: No specific ones as yet -------------- 4. Timeframes -------------- We have identified the following broad and hopefully realistic timeframes for Windows Sockets Version 2. May (Interop) - Windows Sockets 2 Kick Off (See below) June 30, 1994 - Functionality Groups Functionality Proposals Complete August 31, 1994 - Functionality Groups First Drafts Complete November 30, 1994 - Functionality Groups Intermediate Drafts Complete January 1, 1995 - Functionality Groups Final Drafts Complete April 30, 1995 - Windows Sockets Version 2 Specification Final --------------------- 5. Discussion Forums --------------------- Email & Newsgroup details With the recent reorganization of the Windows newsgroups, we see a need to: 1. Create a new list for WinSock 2.0 2. Shift the mailing list gated to alt.winsock 3. Re-think winsock-hackers and winsock-users. Here are the new networking-related newsgroups comp.os.ms-windows.networking.tcp-ip Windows and TCP/IP etworking comp.os.ms-windows.networking.windows Windows' built-in networking comp.os.ms-windows.networking.misc Windows and other networks comp.os.ms-windows.programmer.networks Network programming For the current mailing lists we propose to 1. Gate the present winsock mailing list to comp.os.ms-windows.networking.tcp-ip (since, although winsock is not only for TCP/IP, 95% of the traffic on the mailing list is about TCP/IP). 2. Gate winsock-hackers to comp.os.ms-windows.programmer.networks. 3. Drop winsock-users because of minimal usage. For Windows Sockets Version 2 discussion we propose to 1. Create a new mailing list,winsock-2@SunSite.UNC.Edu, for discussion of general issues related to Windows Sockets version 2.0. 2. Create separate mailing lists for individual Review Boards and Functionality Groups. None of these will be gated to a newsgroup, to facilitate focussed discussion. ------------- 6. Key Dates ------------- April 21, 1994, TCP/IP Bake-Off, hosted by Microsoft, Seattle WA Windows Sockets 2 - Informal evening dinner meeting April 21 - 22, TCP/IP Bake-Off, hosted by Microsoft, Seattle WA WinSockathon IV Tuesday May 3 1994, Interop, Las Vegas NV Windows Sockets 2 - Official Kick Off -------------------- 7. Actions Required -------------------- The official Windows Sockets 2 kick-off will take place at Interop, Las Vegas. Interop is really the godfather of Windows Sockets so it's a particularly appropriate venue. If you wish to attend that event discussion please 1. Email the following details to Marty Bickford (martinb@jsbus.com) Name Company Address Contact Telephone Phone Number Please note space is limited and preference will be given to the first person from a particular company who sends such an email. 2. Consider this document the informal working agenda for now, (a formal agenda will be published). ------------------------------------------------------------------------- Martin Hall 108 Whispering Pines Drive, Suite 115 JSB Corporation Scotts Valley, California 95066 martinh@jsbus.com Tel: 408-438-8300 Fax: 408-438-8360 From paul@atlas.dev.abccomp.oz.au Wed Apr 27 09:32:34 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA20712; Wed, 27 Apr 1994 00:21:19 -0400 Received: by usage.csd.unsw.OZ.AU id AA12212 (5.65c/IDA-1.4.4 for winsock-users%sunsite.unc.edu); Wed, 27 Apr 1994 14:19:05 +1000 Received: by atlas (4.1/1.35) id AA15095; Wed, 27 Apr 94 14:32:35 EST Message-Id: <9404270432.AA15095@atlas> From: paul@atlas.abccomp.oz.au Date: Wed, 27 Apr 1994 14:32:34 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: jimg@nsmdserv.cnd.hp.com, Multiple recipients of list Subject: Re: Local communications optimized? Thus expounded Jim Greuel X2493 on Apr 26, 6:44pm: /-------------------- |Are there any winsock implementations which optimize local |communications (i.e., communications in which the "remote" |socket is actually on the local node) by using some local IPC |mechanism rather than sending the data down the networking |stack, ala Unix domain sockets? Jim, What other IPC mechanism did you have in mind - sending a windows message to yourself? :) Why go the long way round sending the data to yourself when you can simply pass it down your own code chain and back up again? Local communications usually only gets down to the IP layer, which recognises the packet is for the local machine and passes it back up to the transport layer - or would you prefer the Transport layer (UDP or TCP) recognise the other socket the data is destined for and queue it directly instead of passing it down to IP and back again? -- 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 jimg@nsmdserv.cnd.hp.com Wed Apr 27 02:23:07 1994 Received: from hp.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA03007; Wed, 27 Apr 1994 10:23:10 -0400 Received: from nsmdserv.cnd.hp.com by hp.com with SMTP (1.36.108.7/15.5+IOS 3.13) id AA18768; Wed, 27 Apr 1994 07:23:09 -0700 Received: by nsmdserv.cnd.hp.com (1.37.109.8/15.5+ECS 3.3) id AA07730; Wed, 27 Apr 1994 08:23:07 -0600 From: "Jim Greuel X2493" Message-Id: <9404270823.ZM7728@nsmdserv.cnd.hp.com> Date: Wed, 27 Apr 1994 08:23:07 -0600 In-Reply-To: paul@atlas.abccomp.oz.au "Re: Local communications optimized?" (Apr 27, 2:32pm) References: <9404270432.AA15095@atlas> X-Mailer: Z-Mail (3.0.0 15dec93) To: paul@atlas.abccomp.oz.au, Multiple recipients of list Subject: Re: Local communications optimized? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Apr 27, 2:32pm, paul@atlas.abccomp.oz.au wrote: > Subject: Re: Local communications optimized? > Thus expounded Jim Greuel X2493 on Apr 26, 6:44pm: > /-------------------- > |Are there any winsock implementations which optimize local > |communications (i.e., communications in which the "remote" > |socket is actually on the local node) by using some local IPC > |mechanism rather than sending the data down the networking > |stack, ala Unix domain sockets? > > Jim, > What other IPC mechanism did you have in mind - sending a windows > message to yourself? :) Why go the long way round sending the data to > yourself when you can simply pass it down your own code chain and > back up again? You're right. The optimal way to deal with this is to directly queue the data up for the recipient. I guess I didn't want to bias the question by implying a particular implementation. > > Local communications usually only gets down to the IP layer, > which recognises the packet is for the local machine and passes > it back up to the transport layer - or would you prefer the > Transport layer (UDP or TCP) recognise the other socket the data is destined > for and queue it directly instead of passing it down to IP and back again? Actually, I'd prefer that winsock do it. Eliminates unnecessary processing. P.S., Are we experiencing massive delays in the list server? I thought I posted this query about a month ago. > > > -- > 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 | >-- End of excerpt from paul@atlas.abccomp.oz.au -- Jim Greuel Network and System Management Division Hewlett-Packard, A2-1LR6 Email: j_greuel@hpcnd.cnd.hp.com 3404 E Harmony Rd. Telephone: (303)229-2493 Ft. Collins, CO 80525 Fax: (303)229-3526 From Mike_Hopper.XRCC@xerox.com Fri Apr 29 05:12:22 1994 Received: from alpha.Xerox.COM by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA14575; Fri, 29 Apr 1994 15:12:40 -0400 Received: from XRCC_Mail2.XRCC.XEROX.xns by alpha.xerox.com via XNS id <14814(5)>; Fri, 29 Apr 1994 12:12:30 PDT X-Ns-Transport-Id: 0800370069109A573183 Date: Fri, 29 Apr 1994 12:12:22 PDT Sender: Mike_Hopper.XRCC@xerox.com From: hopper.XRCC@xerox.com Subject: How to subscribe to winsock-users mailing list? To: winsock-users@sunsite.unc.edu Cc: hopper.XRCC@xerox.com Reply-To: hopper.XRCC@xerox.com Message-Id: <"29-Apr-94 15:12:18".*.Mike_Hopper.XRCC@Xerox.com> Importance: Normal I have been unable to figure out how to subscribe to the winsock-users group mail list. There does not seem to be a winsock-users-request@sunsite.unc.edu mail address nor a winsock-request@sunsite.unc.edu address. Thanks Mike Hopper Xerox Research Center of Canada