SimpleSock is reliable and easy to use, but it is also complex and relatively inefficient. It was originally designed as a replacement for the Winsock Control, and many of the functions presented were not absolutely necessary. There were also a number of improvements made to Winsock2 (WS2_32.dll) that were not necessarily taken advantage of. So I decided to develop a simpler and faster version.
Objectives:
- Support normal TCP only (SOCK_STREAM, IPPROTO_IP).
- Use simple Module (Class module not beyond consideration).
- Try to use the same Module for both Client and Server.
- Try to use fixed byte arrays instead of variable length arrays.
- Support either IPv4 or IPv6.
Explanation:
The Client was developed first because it could be done without using callbacks. That is to say that a message could be sent to the Client and recovered manually by using the "recv" API call.
The Server on the other hand has to use callbacks in order to place the Server in listening mode and respond to a connection request. It has to create a socket (WSASocketA API), bind to that socket (bind API), and then place it in the listening mode (listen API). When a connection request is received by the Server, it has to create another socket and accept the connection request on the new socket (accept API). Once that connection is established, the callback routine will receive a "FD_WRITE" system message (2). This message simply informs us that the system outgoing buffer is empty and ready to receive data.
In our little example, the Client has created it's own socket when the Server accepted the connection and uses the "send" API to send data to the system outgoing buffer. The buffer will automatically send the data to the Server in packets. The outgoing and incoming buffers are more than likely rotary buffers that use pointers to determine what part of the 64K buffer is currently being used. A single packet can quite easily contain parts of two different records.
The Server receives that data via the "recv" API, and responds appropriately via our program using the "send" API. For example, if the Client requested the "date?", the Server responds with the current date.
These are nonblocking or asynchronous programs, and it is quite possible that the system "send" buffer could fill up. If this happens, a "WSAEWOULDBLOCK" error is returned and the system waits until there is adequate room available. The same is theoretically possible with the "recv" function, but I have not encountered that problem yet, as the operating system is much faster than the network sub system.
If you are going to connect via the network rather than the loopback address (127.0.0.1), be aware that your firewall may restrict access to the Server while in the IDE. If you compile the programs and run the Server, your system should prompt you to allow access.
This is a work in progress and feedback is welcome. Please be aware that the callback routines will prevent you from stopping the program or stepping through it. I used Debug.Print to troubleshoot it.
J.A. Coutts
Objectives:
- Support normal TCP only (SOCK_STREAM, IPPROTO_IP).
- Use simple Module (Class module not beyond consideration).
- Try to use the same Module for both Client and Server.
- Try to use fixed byte arrays instead of variable length arrays.
- Support either IPv4 or IPv6.
Explanation:
The Client was developed first because it could be done without using callbacks. That is to say that a message could be sent to the Client and recovered manually by using the "recv" API call.
The Server on the other hand has to use callbacks in order to place the Server in listening mode and respond to a connection request. It has to create a socket (WSASocketA API), bind to that socket (bind API), and then place it in the listening mode (listen API). When a connection request is received by the Server, it has to create another socket and accept the connection request on the new socket (accept API). Once that connection is established, the callback routine will receive a "FD_WRITE" system message (2). This message simply informs us that the system outgoing buffer is empty and ready to receive data.
In our little example, the Client has created it's own socket when the Server accepted the connection and uses the "send" API to send data to the system outgoing buffer. The buffer will automatically send the data to the Server in packets. The outgoing and incoming buffers are more than likely rotary buffers that use pointers to determine what part of the 64K buffer is currently being used. A single packet can quite easily contain parts of two different records.
The Server receives that data via the "recv" API, and responds appropriately via our program using the "send" API. For example, if the Client requested the "date?", the Server responds with the current date.
These are nonblocking or asynchronous programs, and it is quite possible that the system "send" buffer could fill up. If this happens, a "WSAEWOULDBLOCK" error is returned and the system waits until there is adequate room available. The same is theoretically possible with the "recv" function, but I have not encountered that problem yet, as the operating system is much faster than the network sub system.
If you are going to connect via the network rather than the loopback address (127.0.0.1), be aware that your firewall may restrict access to the Server while in the IDE. If you compile the programs and run the Server, your system should prompt you to allow access.
This is a work in progress and feedback is welcome. Please be aware that the callback routines will prevent you from stopping the program or stepping through it. I used Debug.Print to troubleshoot it.
J.A. Coutts