|
||||
The group responsible for creating WinSock made some very good decisions very early in the process--the most important of which was to follow the sockets model. First introduced in the Berkeley UNIX Software Distribution in the early 1980s, the concept of sockets was originally designed as a method of interprocess communication. Soon, however, it grew to encompass network communications as well. The Berkeley sockets model conceptualizes network communications as taking place between two endpoints, or sockets. Analogies have been drawn that compare plugging an application into a network to plugging a handset into the telephone system, or an appliance into an electrical system. . WinSock Extensions to the Berkeley API With some exceptions, WinSock includes the complete Berkeley sockets API. A large subset of the Berkeley sockets library is available in WinSock with identical function names and parameters. WinSock also offers additional functions that are used to cope with the cooperative multitasking nature of 16-bit Windows. (All of these extension functions are prefixed with the letters WSA). The WinSock API is related closely enough to the Berkeley sockets library that a lot of software can be (and has been) ported from UNIX to Windows. The Client/Server Model Most sockets programs — under Unix or Windows — utilize a client/server approach to communications. Rather than trying to start two network applications simultaneously, one application is theoretically always available (the server) and another requests services as needed (the client). The server creates a socket, "names" it so that it can be identified and found by a client, and then listens for service requests. A client application creates a socket, finds a server socket by name or address, and then "plugs in" to initiate a conversation. Once a conversation is initiated, data can be sent in either direction. The client can send data to and receive data from the server, and the server can send data to and receive data from the client. The specifics of the conversation are unique to each set of client and server applications. Both applications must know what messages and data to expect from the other, and both must follow some mutual rules about when to send and when to expect to receive data. In order to successfully communicate, both the client and the server must speak the same language—they must both use the same protocols (like HTTP, POP, FTP, etc.). Bear in mind that the concept of a socket is purely an abstraction used in the WinSock API. It’s not necessary that client and server applications both be written with WinSock in order to communicate. WinSock is a source code interface--a way for programmers to envision network connections. It’s not a protocol or network type. A program written with WinSock can communicate with many different types of systems, as long as they use the same protocols. For example, a Web Browser written with WinSock can retrieve files from a Web Server written for a different operating system in a different language with a different network interface. As long as both programs "speak" the same transport protocol (like TCP/IP) and the same application protocol (like HTTP) then they can communicate. More About WinSock: |
||||
Home | Example Source Code | WinSock Specifications | Development Files | Related Links |
||||
