I copied this from the GT.M sourceforge site a while back and cleaned it up for my own use so I could read it more easily. I believe it was written by Franz Witte.

https://sourceforge.net/docman/display_doc.php?docid=1593&group_id=11026 and examples here


GT.M Socket Device Summary

This document summarizes the GT.M Socket Device Interface. The complete document, including the sample programs is found in the FTP area of this project. The intended readers of this document are (GT.)M programmers who need to write GT.M programs that interface with other TCP/IP processes.

The GT.M Socket Device Interface is the successor of the GT.M TCP Device Interface. It is closer to the MDC standard in its format and functionality. Major improvements over the GT.M TCP Device Interface lie in the delimiter handling and the device organization. There are, however, some deviations from the MDC standard, that relate directly to the GT.M model:

In most operating environments the system maintains a "pool" of sockets. A program that needs to cummunicate over the network will request a socket (from the system), use it for a network connection, and return the socket (to the system). One program can work with multiple sockets, and sockets can often be passed to different processes. This model of handling and passing sockets is essential for many internet-based services.

The other important model in this context is the TCP/IP client-server model. In this model, there are servers, that provide services, and clients that request services. The essential difference is that the server is more or less "passive", whereas the client "actively" requests a service. The following steps depict the general flow of this model:

  1. The server is started.
  2. The server allocates a socket, and uses that socket to "bind" to a predefined, and well-known service port.
  3. The server starts "listening" for incoming connection requests through the socket that is bound to the service port. Incoming requests are queued, and the server specifies the "depth" of this listen queue.
  4. A client actively connects to the predefined port.
  5. At the server side, a new socket is allocated when the connection request arrives. The new socket is passed to the server. From this moment two sockets are associated with the server: the "listen" socket, and the "connection" socket.
  6. The server decides to accept, or to reject the connection. Similarly, the server decides to continue listening for new connection requests, or stop listening (by closing the "listen" socket).
  7. If the server accepts the connection, the client and the server can exchange information (through the "connection" socket) until either side decides to close the connection.
  8. After closing the connection, both the server, and the client release their "connection" socket.

The example client program connects to a specified host, at a specified port, sends one or more requests to the server, closes the connection and quits. The most important steps are discussed here:

The example single connection server program opens a socket device, listens for an incoming connection, handles the requests from that connection, and quits. The most important steps are discussed here: