44.htm

网络编程原理文摘 [文件] 精华区目录结构 [目录] 网络编程的基本原理 [目录] 网络编程与网络协议 [目录] 网上资源 [目录] winsock技术 [目录

  <br>

1.6 - Is there a version of Winsock for...? <br>

  <br>

     ...DOS? <br>

  <br>

          Not as such. The main problem is that Winsock depends greatly on Windoows' messaging architecture; plus, DOS <br>

          lacks the ability to use DLLs such as Winsock. However, there are a feew BSD sockets and sockets-like network <br>

          stacks for DOS available. <br>

  <br>

          Erik Engelke's Waterloo TCP package is a freeware TCP/IP stack that ruuns over Crynwr-style packet drivers. <br>

          I've used it myself, and it works very well. <br>

  <br>

          Another option is JSB's Virtual Socket Library. It implements a commonn BSD sockets API for DOS, Windows, <br>

          Windows NT, OS/2 and UnixWare programmers. This is probably a better ooption if you need BSD sockets <br>

          compatibility and multiplatform support. I've not used it, though, so I can't actually endorse it. <br>

  <br>

          Finally, FTP Software offers the PC/TCP Software Development Kit for DDOS. This is roughly the same thing as <br>

          the JSB product, and since I haven't used this library either, I won'tt comment further on it. <br>



  <br>

          I have recently come across one other rather interesting alternative: the WSock library for the DJGPP compiler. <br>

          This library accesses the wsock.vxd or wsock.386 driver used by Microssoft's Windows for Workgroups 3.1 and <br>

          Windows 95 Winsock stacks. Naturally these drivers only work while Winndows is running, so you have to run <br>

          such a DOS application in a DOS box. This method does have a number off advantages: the DJGPP compiler is <br>

          free, and the fact that it lets you program a Winsock application withhout writing a GUI can be a plus. My view, <br>

          however, is that if you can afford a decent Win32 compiler and can stiipulate that your program must run on <br>

          Windows 95 or Windows NT, you can get this same low overhead by writinng a console mode program. Also note <br>

          that Cygnus Solutions is porting the free GNU tools (including the C aand C++ compilers) to Win32 with their <br>

          GNU-Win32 effort. The system is better than and worse than DJGPP, depeending on which part you're looking at, <br>

          but at least it generates true Win32 executables. <br>

  <br>

     ...UNIX? <br>

  <br>

          Most UNIXes include some form of TCP/IP library (BSD sockets in most, TLI or XTI in the unfortunate <br>

          remainder), so there isn't much need for Winsock on UNIX. <br>

  <br>

     ...OS/2? <br>

  <br>

          IBM offers the "TCP/IP for OS/2" add-on package (read: extra cost) whiich supports the Winsock API. I've also <br>

          heard that newer versions of OS/2 Warp include this functionality in tthe package, but since I've never really used <br>

          OS/2, I couldn't say for sure. <br>



  <br>

     ...Win32s? <br>

  <br>

          Yes. Win32s 1.1 contains a WSOCK32.DLL that thunks calls down to a 16--bit WINSOCK.DLL, if present. I <br>

          have successfully used Win32s to run 32-bit Winsock programs over Trummpet Winsock and Microsoft's <br>

          Wolverine stack. <br>

  <br>

1.7 - Can Winsock speak { DECNet, IPX/SPX, etc. }? <br>

  <br>

     Winsock 1.1 only provided real support for TCP/IP. However, Microsoft, Noveell and a few other vendors did provide <br>

     NetBIOS, IPX/SPX and other support through Winsock, but the point is that tthis support was never standardized in the <br>

     Winsock specification. <br>

  <br>

     Winsock 2 changed this by providing standardized support for DECNet, IPX/SPPX and OSI. Support for other <br>

     LAN/WAN protocols are likely to follow. <br>

  <br>

1.8 - What does Winsock 2 have that Winsock 1.1 doesn't? <br>

  <br>

     One of the most important new features is official support for multiple traansport protocols. Although Winsock 1.1 was <br>

     not actually limited to TCP/IP, that was the only protocol that had officiaal support written into the spec. There was no <br>

     standard way for a vendor to add support for another transport protocol, annd as far as I can tell, no one did. With <br>

     Winsock 2, official support for OSI, Novell IPX/SPX and Digital's DECNet exxists in the spec, and it's now possible to <br>



     add support for other protocols in a standard way. More importantly, a proggram can be written to be <br>

     transport-independent, so that it works with all of these protocols, withouut change. <br>

  <br>

     Winsock 2 also adds support for technical initiatives like Quality of Serviice and Multicasting. These technologies will <br>

     become increasingly important as bandwidth requirements become more regimennted and intense. For example, the QoS <br>

     mechanism would allow a videoconferencing program to reserve a certain amouunt of bandwidth so that a sudden file <br>

     transfer, for example, doesn't cause its video to begin breaking up due to a lack of bandwidth. <br>

  <br>

     The multicasting support would allow you to hold a videoconference with mulltiple people on the same LAN but have <br>

     each video phone only send a single stream of data. (The current alternativve requires every phone to send a stream of <br>

     data to every other conference particpant. This is wasteful and can quicklyy bog down a common LAN.) <br>

  <br>

     Another important feature of Winsock 2 is complete integration with Win32'ss unified I/O mechanisms. For example, it is <br>

     possible to use the Win32 ReadFile() API on a socket instead of recv(). Morre importantly, Windows NT's <br>

     overlapped I/O mechanisms can now be used with sockets; Winsock 2 on Windowws 95 also implements overlapped I/O <br>

     with sockets, though it is faked, because Windows 95 does not support overllapped I/O natively. <br>

  <br>

     Winsock 2 also allows for "Layered Service Providers." This enables many neeat things, such as security plug-ins: drop in, <br>

     say, an SSL service provider, and all of a sudden your data is automaticallly encrypted. Rumor has it that Windows NT <br>

     5.0 will include such a layer, for example. <br>

  <br>

     There are a number of other additions to the spec. You can get a complete llist of them on sockets.com's Winsock 2 <br>

     There are a number of other additions to the spec. You can get a complete llist of them on sockets.com's Winsock 2 <br>

     Overview page. <br>

  <br>

1.9 - Where can I get Winsock 2? <br>

  <br>

     Windows NT 4.0 already comes with Winsock 2 support, and Windows 98 ("Memphhis") will have it. Unfortunately, <br>

     Winsock 2 will not run on Windows 3.1 or Windows NT 3.51, so those users wiill have to upgrade or stick with <br>

     Winsock 1.1. <br>

  <br>

     Windows 95 still comes with Winsock 1.1, but the final Winsock 2 SDK for Wiindows 95 is now available. This <br>

     package comes with a full set of freely redistributable components which yoour program's installer can use to upgrage a <br>

     stock Windows 95 system to Winsock 2. <br>

  <br>

-- <br>

人生在世，如果不能喝酒，不能想女人，连人家欺负到了头上也不能还手，还不如死了算了了  <br>

  <br>

※ 修改:·Christopher 於 Feb 27 10:07:40 修改本文·[FROM:  166.111.74.189] <br>

※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 166.111.74.189] <br>

发信人: Christopher (Chris), 信区: Winsock <br>

标  题: Re: 一个不错的Winsocket站点 <br>

发信站: BBS 水木清华站 (Fri Feb 27 10:09:59 1998) <br>

  <br>

【 在 Christopher (Chris) 的大作中提到: 】 <br>



贴出第二部分，建议用WWW方式浏览。 <br>

Section 2 - Issues for New Winsock Programmers <br>

  <br>

2.1 - Are there any sample apps on the Net? <br>

  <br>

     Yes. There are several listed on the Resources page, and my Examples sectioon has several more. However, all of my <br>

     current examples simply illustrate API calls and general principles, not too teach you how to start with Winsock, so you <br>

     are probably better off starting with the sample programs linked in the Ressources section. <br>

  <br>

2.2 - Are there standard APIs for { FTP, Telnet, HTTP, etc. }? <br>

  <br>

     Not as part of the Winsock specification. One option would be to write yourr own implementation of the protocol, using <br>

     the Internet's RFC series. RFCs are the Internet's standards mechanism. As far as standards go, they are generally <br>

     clearly-written, though few of the standard protocols are intrinsically simmple. You can visit my Important RFC Lists site <br>

     for more information on major RFCs. <br>

  <br>

     The other option is to purchase one of the many Winsock-compatible protocoll libraries available. Several companies sell <br>

     these libraries now, and there are also a number of shareware alternatives.. See the Resources page for more information. <br>

  <br>

     Another option is the WinInet API, which is installed with Microsoft's Inteernet Explorer. Current versions of Microsoft's <br>

     development tools include support for this API, and the highly-recommended MSDN package includes further <br>

     documentation on these APIs. WinInet allows a program to speak HTTP, FTP annd gopher with a minimum of fuss. <br>



  <br>

2.3 - How do I get my IP address from within a Winsock program? <br>

  <br>

     There are three methods, which each have advantages and disadvantages. <br>

  <br>

     To get the local IP address if you already have a bound or connected sockett, just call getsockname() on the socket. <br>

     (By the way if you call getsockname() on a bound but unconnected socket, yoou will most likely get the same address <br>

     you asked for when you set up the sockaddr_in structure, usually INADDR_ANYY, which is 0.0.0.0.) <br>

  <br>

     To get your address without opening a socket first, do a gethostbyname() onn the output from gethostname(). This <br>

     will return a list of all the addresses of the local host's interfaces, as shown in the example. [C++ example] <br>

  <br>

     There are several problems with this method. The first is that it has probllems on multi-homed machines, because <br>

     gethostbyname returns all of the local machine's addresses, only one of whiich belongs to the interface you're interested <br>

     in. (This can also be a feature, of course.) <br>

  <br>

     This method also requires that your local machine actually has a name, and that the DNS can find an address given that <br>

     name. On Windows 95 and Windows NT this is not a problem if you set up the "Host Name" field in the DNS tab of the <br>

     TCP/IP protocol setup screen. Winsocks on Windows 3.1, of course, function differently. <br>

  <br>

     Another problem is that Windows 95 doesn't deal well with DNS and multi-hommed machines. The new Dial-Up <br>

     Networking 1.2 (DUN) patches help this (or is it the Winsock 2 stuff?), butt they aren't foolproof. The problem is that <br>



     DUN will often try to start up your dial-up adapter when you make the gethoostbyname() call, because it initially tries <br>

     your ISP's DNS, even though the required information is actually available locally. <br>

  <br>

     The third method only works on Winsock 2. The new WSAIoctl() API supports tthe SIO_GET_INTERFACE_LIST <br>

     option, and one of the bits of information returned is the addresses of eacch of the network interfaces in the system. This <br>

     API is not perfect: it returns different, though usable, results on Windowss 95 and Windows NT. On the other hand, it <br>

     works without being connected to a host and without the aid of DNS. [C++ Exxample] <br>

  <br>

2.4 - What kind of socket should I use? <br>

  <br>

     The short answer for clients is to use asynchronous sockets. The short answwer for servers is to use blocking sockets with <br>

     one thread per socket, or if you can use Winsock 2, overlapped I/O. The lonng answer is in Tutorial 1. <br>

  <br>

2.5 - Do I need to initialize the WSAData structure before calling WSAStartup? <br>

  <br>

     No, WSAStartup() fills this structure in for you. <br>

  <br>

2.6 - If I write a Winsock program, will I be able to communicate with a UNIX soockets program? <br>

  <br>

     Absolutely! This common question is the result of confusing protocols with the APIs. Communicating programs need not <br>

     have been created with the same APIs, as long as they are using the same trransport and network protocols. <br>

  <br>

  <br>

2.7 - Can I use Winsock with { Delphi, Visual Basic, Visual Cobol, etc. }? <br>

  <br>

     Delphi 3 and Visual Basic 5 include Winsock controls in the package. Also, Delphi and Visual Basic versions 4 and <br>

     newer can talk directly to the Winsock API. Details on the latter are on Reesources page. <br>

  <br>

     As for other languages, it should be pointed out that some languages are "iinsufficiently rich" to allow you to call directly <br>

     into Winsock. For example, older versions of Visual Basic (version 3 and eaarlier) and many scripting languages simply <br>

     lack the language constructs required to make direct Winsock API calls. To use Winsock with these languages, you must <br>

     use a Winsock control (e.g. an ActiveX control). The Resources page includees links to a number of these controls. <br>

  <br>

2.8 - How do I detect when the connection is closed? <br>

  <br>

     Use asynchronous sockets. These are more complex than simple blocking sockeets, but their benefits are much greater <br>

     than their bother. In this specific case, you can simply call WSAAsyncSelecct() with the FD_CLOSE option; Winsock will <br>

     then send you a message when the connection closes, normally or otherwise. <br>

  <br>