UdpSocket class: Difference between revisions

From m204wiki
Jump to navigation Jump to search
Line 21: Line 21:


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.
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==
The first step


==List of UdpSocket methods==
==List of UdpSocket methods==
[[List of UdpSocket methods|"List of UdpSocket methods"]] shows all the class methods.
[[List of UdpSocket methods|"List of UdpSocket methods"]] shows all the class methods.

Revision as of 22:53, 21 April 2012

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 establish context for the exchanged data.

UDP and TCP both have many higher-level protocols layered above them and, in general, it's preferable to use the higher-level protocols as they tend to take care of more of the interaction details. For example, if a client wishes 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; with HTTP Helper providing a client API and Janus Web Server providing 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, so 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 Sockets 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 blush, specifically 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's 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 so 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, because asynchronous processing with TCP raises some difficult issues, it is not current available in the Janus suite. However, UDP's connection-less 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 receives 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

The first step



List of UdpSocket methods

"List of UdpSocket methods" shows all the class methods.