UdpSocket class

The UdpSocket class allows User Language programs to send and receive UDP (User Datagram Protocol) messages. Both client and server applications may be written using the UdpSocket class.

Note: To use the UdpSocket class, you must have licensed Janus Sockets and Janus SOAP.

Why UDP?

The User Datagram Protocol is a low-level communications protocol that provides an alternative to TCP. The two main features that distinguish UDP from TCP are that it is connectionless and that it is message based.

UDP is connectionless in that UDP does not establish a connection between two endpoints in a conversation. Instead, messages are simply sent between two endpoints. Because there is no connection between the endpoints, the messages are each independent units and it is up to the applications that use UDP to establish context for the messages. TCP, is a connection-based protocol where a connection is established between two endpoints and then data is streamed between the two end-points. Once the connection is established, the connected socket establishes context for the exchanged data.

UDP and TCP both have many higher-level protocols layered above them and, in general, it is preferable to use the higher-level protocols as they tend to take care of more of the interaction details. For example, if a client wants to use a request/response protocol to communicate with a server, HTTP provides an ideal communications protocol. Most systems provide both client and server HTTP APIs. Model 204 is no exception: HTTP Helper provides a client API and Janus Web Server provides a server API.

However, there might be reasons to use a lower-level TCP or UDP API. The first is that there might not be an API to support a required protocol. For example, there is currently no telnet client API available in Model 204, though if one is required, it might be possible to use the Janus Sockets API to implement the required parts of the telnet protocol using the Socket class.

While there are not as many protocols layered over UDP, there are a few commonly used ones. These include Domain Name System (DNS) and Simple Network Management Protocol (SNMP). So, one reason to use UDP would be to use these protocols from a User Language request.

Another reason to use UDP might seem odd, at first: the use of UDP as a client/server application level API. While it might seem odd using a low-level protocol like UDP for an application level communication protocol, it does have some things to recommend it. First, because it is message-based rather than stream-oriented like TCP, the protocol takes care of encapsulating messages so they are sent and received by applications as a single entity (called a datagram). Using TCP directly from an application is quite complex because TCP is stream oriented, so applications must add message boundaries into the stream and piece together pieces of a stream into a message.

In addition, because UDP is connectionless, it is extremely lightweight and therefore very efficient. An application request/response will generally consist of a single packet going in each direction between the two endpoints. TCP will often require three packets to be exchanged to set up the connection and another two to close the connection. This, in addition to the packets used for data exchange. In addition, because the TCP layer has to manage the connection, there is a fair amount of overhead in the TCP layer.

A final reason for using UDP is that it facilitates asynchronous processing in User Language. Admittedly, this should also be possible with TCP, but asynchronous processing with TCP raises some difficult issues, so it is not currently available in the Janus suite. However, UDP's connectionless paradigm makes it possible to send multiple messages, possibly to different hosts or ports, without waiting for the messages to be received by the target or even sent on the network. In addition, a UDP application could wait for a request or response on a UDP socket and receive the messages in the order they arrive, without having to wait on a specific one.

The main downside of using UDP as an application-level transport is that delivery is not guaranteed. In fact, UDP provides no way of knowing whether the target host or port is available. While this might seem like a fatal problem, the reality is that even a so-called "reliable" protocol like TCP might fail to establish a connection (for example if the target port is down), so code that uses TCP or a higher-level protocol layered over TCP must deal with failures at the TCP level. As such, the work required to deal with a lack of response for a UDP request is not significantly greater than that required for a TCP request.

Getting started

As with other Janus APIs, the first step in using UDP sockets is defining a port or ports over which messages are to be sent. You do this with the JANUS DEFINE command. As with the low-level Janus sockets API, there are two port types: client and server. The client port type for UDP is called CLSOCKU, and the server port type is called SRVSOCKU. The main difference between these port types and the equivalent TCP socket port types (CLSOCK and SRVSOCK) is that instead of establishing or accepting connections, the CLSOCKU and SRVSOCKU ports simply send and receive messages.

One other significant difference between CLSOCKU and CLSOCK ports is that an application running on a single thread can essentially act as a server. You do this by binding to a particular port number (and possibly IP address) when the UdpSocket object is instantiated. The application can then simply wait for messages to be received, then process and possibly respond to them. The advantage of this approach over using a SRVSOCKU approach is that no more than one thread is ever used for the server. Also, the processing of requests can be more efficient, as there would be no start-up costs for the application.

On the other hand, using a CLSOCKU port for a server application means that any overlap in the processing of requests must be managed by the application, a task that can be quite complex. Also, for a server application that is not especially busy, using a CLSOCKU port unnecessarily ties up a Model 204 thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a SRVSOCKU port.

List of UdpSocket methods

List of UdpSocket methods shows all the class methods.