Windows Socket Programming - Felix John COLIBRI.

• abstract : presents Windows Socket Programming using the WinSock API calls from Delphi
  
• key words : socket, WinSock, Send, Recv, Bind, Accept, Connect, Client / Server
  
• software used : Windows XP, Delphi 6
  
• hardware used : Pentium 1.400Mhz, 256 M memory, 140 G hard disc
  
• scope : Delphi 1 to 8 for Windows
  
• level : Delphi developer
  
• plan :
  
  • Introduction
    
  • Socket Communication
    
  • The Delphi Code
    
  • What's Next ?
    
  • Download the Sources
    

1 - Introduction

2 - Socket Communication

2.1 - The File Model

The main difference between a file system and a network is that the file system is always available and ready (the Os offers services which are always present), whereas the remote PC has to be located and checked for availability.

So the basic model of communication between 2 PCs thru a network is a Client Server model:

• the Server is started and waits for Clients
  
• when any client wants to communicate, it searches the Server, then opens a communication, and this commnication will continue until either the Server or the Client decide to stop.
  

When the Client has located the Server, it must tell the server what the purpose of the communication is: retrieve some mail, send a file, download a web page etc.. This is somehow similar the to file extension: .EXE, .TXT etc. The type of service is encoded in a number called a service or a Port. For instance 80 is the port for retrieving web pages, 110 the port for retrieving mails etc. The port is associated with a protocol which specifies the format and structure of the communication. For mail retrieval, the Server is prepared to send a list of available e-mails, send then content of a specified e-mail or delete a specified e-mail. And the Client can get the list, get or delete an e-mail.

In our example, we will invent a file retrieval service:

• the Port will be 5678
  
• the Client will sent a file name followed by Return LineFeed
  
• the Server will send the file size followed by Return LineFeed and the file bytes
  

2.2 - The Socket

• the local address and Port
  
• the remote address and Port
  

This record is stored in Windows tables, and managed as an opaque structure:

• we create the structure with a Socket call, which returns an handle of type tSocket (a positive integer identifying the structure)
  
• we use this handle for all the socket calls (Connect, Send etc)
  
• we free the structure with a CloseSocket call
  

• the Server is located at, say, 43.3.1.0, and knows how to handle 5678 requests. The Server is started:

• a Client starts at address 3.22.0.1, and tries to connect to (43.3.1.0, 5678):

• the Server receives the request, and both socket records are filled:

2.3 - One Server, Several Clients

Therefore:

• the Server uses a Server socket for welcoming the potential Clients
  
• any new Client first connects to the Server socket:

• the Server creates a new "server client socket", links this new socket to the Client, and the communication will flow between this socket and the Client, while the Server socket will be free to watch for other Clients

• and each new Client uses its own "server client socket":

2.4 - The basic primitives

For the Server:

• Socket creates the record, and returns a handle to this record
  
• Bind tells which address the Server is prepared to receive (usually all)
  
• Listen start the Client welcoming mode
  
• when an Client arrives, Accept creates the socket for this Client
  
• Recv and Send exchange the data
  
• Close terminates the communication to all Clients
  

• Socket creates the record, and returne a handle to this record
  
• Connect sends the requested 4 byte address on the network and returns when the Server has created the client socket
  
• Recv and Send exchange the data
  
• Close terminates the communication
  

2.5 - Windows Sockets

• on the Server side:
  
  • the main program starts a Server thread and continues performing other tasks
    
  • this thread waits for Clients, and then starts a thread for each incoming Client. All Recv and Send are blocking routines: the control returns only after completion. Since the blocking calls are within threads, the main program can still perform other tasks. And while the Client has not finished reading or writing whatever the Server is sending ar receiving, there is nothing else to do anyway.
    
• on the Client side
  
  • the main program starts a Client thread and continues on other jobs
    
  • this thread tries to connect, and blocks until the Server answers. Each Send and Recv is also blocking
    

So, in order to avoid this stop and go mode, some flexibility was introduced allowing the application to still somehow react to user actions. The whole socket library was casted in an event mold using Windows messages:

• on the the Server side:
  
  • after Listen, the control returns to the program.
    
  • when a Client connects, the program receives a fd_connect message, and the program can call Accept to create the new server client socket
    
  • when this new server client socket can send data (there is nothing in the sending buffer), a fd_write message is issued
    
  • after the socket has received some data, an fd_read message is issued
    
  • an fd_close notification tells that the Clients terminated the communication
    
• on the Client side:
  
  • after Connect, the control returns to the program
    
  • and fd_connect message is sent when the connection is established
    
  • the same fd_write and fd_read messages are sent do notify the program about write availability or data reception
    
  • fd_close tells when the server client socket closed
    

Note that:

• on the Client side, the event model allows the application to perform other tasks, but if the main purpose the application is the communication with the Server, introducing messages only adds some responsiveness. All the user can do is to move the window around or play with the mouse. Events won't fetch buffers faster or increase bandwidth
  
• on the Server side, message scheduling is much more usefull: if the Server handles slow and fast Clients, they are decoupled by the message scheduling: the whole Server does not wait until a slow Client has finished its work
  

• use the message notification (asynchronous mode)
  
• use blocking (synchronous) sockets with threads, since threads are now available in Windows 98, NT and later OSes
  
• use blocking (synchronous) sockets without threads (not often used)
  

3 - The Delphi Code

3.1 - The Server Client Socket List

When fd_read is received, the following code retrieves the request, using Recv:

The file is sent to the Client using Send:

Each c_server_client_socket is managed by any kind of object list, like the following tStringList container (partial):

3.2 - The Server

The WinSock library is started with:

The socket structure is initialized with:

We specify which notification we want to receiveve:

And specify the Port we are offering, and start waiting for Clients:

Now the interesting part: whenever the Winsock library wants to notify us, it calls a Windows Message handler:

• The handler is declared in the tForm1 CLASS as a MESSAGE method:

  const wm_asynch_select= wm_User; type TForm1= class(TForm)                // -- buttons etc                procedure handle_wm_async_select(var Msg: TMessage);                    message wm_asynch_select;              end; // tForm1

• the handler itself looks like this

  procedure tForm1.handle_wm_async_select(var Msg: TMessage);   // -- wParam: hSocket, lo(lParam): notification, hi(lParam): error   var l_param: Integer;       l_error, l_notification: Integer;       l_socket_handle: Integer;   // -- here the notification procedures   begin // handle_wm_async_select     l_param:= Msg.lParam;     l_socket_handle:= Msg.wParam;     l_error:= wsaGetSelectError(l_param);     l_notification:= wsaGetSelectEvent(l_param);     if l_error<= wsaBaseErr       then         case l_notification of           FD_ACCEPT: handle_fd_accept_notification(l_socket_handle);           FD_CONNECT: display('no server fd_connect');           FD_WRITE: handle_fd_write_notification(l_socket_handle);           FD_READ: handle_fd_read_notification(l_socket_handle);           FD_CLOSE: handle_fd_close_notification(l_socket_handle);         end // case       else display_socket_error_halt(l_socket_handle,          's.handle_wm_async_select '          + f_socket_notification_name(l_notification), l_error);   end; // handle_wm_async_select

• and for each kind of message, we use a separate procedure. Here is the procedure which creates a new server client socket:

  procedure handle_fd_accept_notification(p_socket: tSocket);   var l_address_socket_in: tSockAddrIn;       l_address_size: Integer;       l_server_client_socket: tSocket;   begin     l_address_size:= sizeof(l_address_socket_in);     l_server_client_socket:= Accept(p_socket, @l_address_socket_in,         @l_address_size);     // -- add to the list to be able to close them     g_c_server_client_socket_list         .f_c_add_unique_server_client_socket(l_server_client_socket);   end; // handle_fd_accept_notification

  and the notification of data reception:

  procedure handle_fd_read_notification(p_socket: tSocket);   var l_c_server_client_socket: c_server_client_socket;   begin     // -- find this server client socket     l_c_server_client_socket:= g_c_server_client_socket_list         .f_c_find_server_client_socket_by_handle(p_socket);     l_c_server_client_socket.handle_fd_read_notification;   end; // handle_fd_read_notification

  
  

Here is a snapshot of the Server (after receiving a Client Connect):

3.3 - The Client

The globals are:

wsaStartup and Socket are same as for the Server.

We select fd_connect, fd_write, fd_read and fd_close:

Connection is established by calling Connect

And we create a message handler nearly identical to the server procedure, with only fd_connect handling (instead of fd_accept), and specific fd_read handling:

The received buffer can then be displayed.

And here is a snapshot of the Client (after Connect but before sending the request):

4 - What's Next ?

4.1 - The libraries

However the basic calls are usually packaged in libraries which offer higher level services: requesting Web pages, sending files etc.

Many such libraries have been created:

• the first Pascal code I saw was from Andreas HORSTEMEIER
  
• several commercial librairies the were offered for Delphi
  
• Delphi itself first uses then NetManage library, and then switched to Indy
  
• 2 mainstream Delphi source librairies are popular:
  
  • ICS from Francois PIETTE, which uses asynchronous windows sockets
    
  • Indy, previously Winshoes, which has smaller units (finer grain) and work with blocking sockets
    

4.2 - To Block or not to Block

• blocking mode code is simpler, since the steps are linear, in a DOS write / read fashion, everything between a BEGIN and an END. However this BEGIN and END is in a thread, so you have to battle with threads (Execute, Synchronize, Terminate, communication with the main GUI thread, critical sections etc)
  
• asynchronous mode avoids thread hassles, but you have to split the work in multiple events called whenever the opposite party has finished a small part of the work
  

WinSock was only created because Windows 3 had no efficent process mechanism (CreateProcess is very expensive, and communication between the spawned processes akward) whereas the fork in Unix is much lighter. Threads were created later to allow multitasking in Windows, and asynchronous sockets are no longer a necessity. But you still have the choice.

5 - Download the Sources

• client_socket.zip: the client socket requesting a file (27 K)
  
• server_socket.zip: the server socket with the server client socket list (29 K)
  

• the main program (.DPR, .DOF, .RES), the main form (.PAS, .DFM), and any other auxiliary form
  
• any .TXT for parameters
  
• all units (.PAS) for units
  

• are self-contained: you will not need any other product (unless expressly mentioned).
  
• can be used from any folder (the pathes are RELATIVE)
  
• will not modify your PC in any way beyond the path where you placed the .ZIP (no registry changes, no path creation etc).
  

• create or select any folder of your choice
  
• unzip the downloaded file
  
• using Delphi, compile and execute
  

As usual:

• please tell us at fcolibri@felix-colibri.com if you found some errors, mistakes, bugs, broken links or had some problem downloading the file. Resulting corrections will be helpful for other readers
  
• we welcome any comment, criticism, enhancement, other sources or reference suggestion. Just send an e-mail to fcolibri@felix-colibri.com.
  
• or more simply, enter your (anonymous or with your e-mail if you want an answer) comments below and clic the "send" button

  Name :
  E-mail :
  Comments * :

• and if you liked this article, talk about this site to your fellow developpers, add a link to your links page ou mention our articles in your blog or newsgroup posts when relevant. That's the way we operate: the more traffic and Google references we get, the more articles we will write.
  

6 - The author