Building a server into your app

Sometimes you need to have a server that can handle multiple connections from multiple clients. You cannot build your own using the TCP classes because you will not be able to ensure you can respond to every request. There are two ways to build your own server.

The first and easiest way is to use a Xojo web app. You might normally think of a web app as have a user interface, but a user interface is not required. You can create a web app and only implement the WebApplication.HandleURL or WebApplication.HandleSpecialURL events so that your server responds to requests send to it. This can be a fast and easy way to create your own server for a web services API, for example.

The other option is to create your own server from scratch building it using the ServerSocket class.

Using a ServerSocket

If you need to communicate with more than one app via the same port, it is difficult to do using the TCPSocket because each TCPSocket can manage only one connection at a time. To use the TCPSocket, you would have to implement a system for managing multiple TCPSockets, as connections are received.

To handle this situation, you should use the ServerSocket class. A ServerSocket is a permanent socket that listens on a single port for multiple connections. When a connection attempt is made on that port, the ServerSocket hands the connection off to another socket, and continues listening on the same port. Without the ServerSocket, it is difficult to implement this functionality due to the latency between a connection coming in, being handed off, creating a new listening socket, and restarting the listening process. If you had two connections coming in at about the same time, one of the connections may be dropped because there was no listening socket available on that port.

To initiate the ServerSocket's listening process, set the port to listen to by assigning a value to the Port property and call the ServerSocket's Listen method. On macOS and Linux, attempting to bind to a port less than 1024 will cause a SocketCore.Error event to fire with an error 105 unless your application is running with root permissions. This is a built-in security feature of Unix-based operating systems. This is not a bug, but a security feature that prevents problems that can arise from allowing sockets to listen on privileged ports.

The ServerSocket control automatically manages a pool of TCPSockets available for use. You don 't create the TCPSockets explicitly; instead you can set the size of this pool using the MinimumSocketsAvailable and MaximumSocketsConnected properties after establishing the listening socket. If you change the MaximumSocketsConnected property, it will not kill any existing connections. It just may not allow more connections until the existing connections have been released. If you change the MinimumSocketsAvailable property, it may fire the AddSocket event of the ServerSocket to replenish its internal buffer.

When you call the ServerSocket's Listen method, it first fills its internal pool of handoff sockets. It does this by calling the AddSocket event. This event will be called until it has enough sockets in the internal pool of available sockets. It adds the number specified by the MinimumSocketsAvailable property, plus ten extra sockets. (Note that if you return Nil from this event, it will cause a NilObjectException.) The ServerSocket is not ready to hand off connections until this process is completed. Connections that come in while the server is populating its pool are rejected. To determine when the ServerSocket is ready to accept incoming connections, check its IsListening property. A ServerSocket can only return a TCPSocket (or a subclass of TCPSocket) in its AddSocket event.

ServerSocket is only for use with TCPSockets. Since UDP is a connectionless protocol, it does not make sense for a ServerSocket to deal with UDPSockets.

Reference counting

The reference count isn 't incremented when you return a socket with the AddSocket method. Instead, the socket is pooled internally and its reference count is incremented when the server hands off a connection to that socket. If the ServerSocket is destroyed before it uses one of these pooled sockets, the unused sockets get destroyed as well. Until that time, the ServerSocket is the parent of the TCPSocket, and so the TCPSocket will remain. If a socket returned from the AddSocket event has been handed a connection and then the ServerSocket is destroyed, the socket will remain connected and continue to function.

See also

ServerSocket class; Accessing Web Services topic