UdpSocket class - Revision history

JAL: add category

2018-04-20T19:07:05Z

add category

← Older revision		Revision as of 19:07, 20 April 2018
Line 33:		Line 33:
	==List of UdpSocket methods==		==List of UdpSocket methods==
	[[List of UdpSocket methods]] shows all the class methods.		[[List of UdpSocket methods]] shows all the class methods.

			[[Category:System classes]]

JAL: add links

2016-09-16T00:02:11Z

add links

← Older revision		Revision as of 00:02, 16 September 2016
Line 2:		Line 2:
	Both client and server applications may be written using the <var>UdpSocket</var> class.		Both client and server applications may be written using the <var>UdpSocket</var> class.

	'''Note:'''		<p class="note">'''Note:'''
	To use the <var>UdpSocket</var> class, you must have licensed <var class="product">Janus Sockets</var> '''and''' <var class="product">Janus SOAP</var>.		To use the <var>UdpSocket</var> class, you must have licensed <var class="product">[[Janus Sockets]]</var> '''and''' <var class="product">[[Janus SOAP]]</var>. </p>

	==Why UDP?==		==Why UDP?==
	The User Datagram Protocol is a low-level communications protocol that provides an alternative to [http://en.wikipedia.org/wiki/Transmission_Control_Protocol TCP]. The two main features that distinguish UDP from TCP are that it is connectionless and that it is message based.		The User Datagram Protocol is a low-level communications protocol that provides an alternative to [http://en.wikipedia.org/wiki/Transmission_Control_Protocol TCP]. The two main features that distinguish UDP from TCP are that it is connectionless and that it is message based.
Line 31:		Line 32:

	==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]] shows all the class methods.

JAL at 19:32, 23 July 2014

2014-07-23T19:32:21Z

← Older revision		Revision as of 19:32, 23 July 2014
Line 11:		Line 11:
	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://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] provides an ideal communications protocol. Most systems provide both client and server HTTP APIs. <var class="product">Model 204</var> is no exception: [[HTTP Helper]] provides a client API and <var class="product">[[Janus Web Server]]</var> provides a server API.		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://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] provides an ideal communications protocol. Most systems provide both client and server HTTP APIs. <var class="product">Model 204</var> is no exception: [[HTTP Helper]] provides a client API and <var class="product">[[Janus Web Server]]</var> 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 <var class="product">Model 204</var>, though if one is required, it might be possible to use the <var class="product">[[Janus Sockets]]</var> API to implement the required parts of the telnet protocol using the <var>[[~~Sockets~~ class\|~~Sockets~~]]</var> class.		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 <var class="product">Model 204</var>, though if one is required, it might be possible to use the <var class="product">[[Janus Sockets]]</var> API to implement the required parts of the telnet protocol using the <var>[[Socket class\|Socket]]</var> class.

	While there are not as many protocols layered over UDP, there are a few commonly used ones. These include [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] and [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol (SNMP)]. So, one reason to use UDP would be to use these protocols from a <var class="product">User Language</var> request.		While there are not as many protocols layered over UDP, there are a few commonly used ones. These include [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] and [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol (SNMP)]. So, one reason to use UDP would be to use these protocols from a <var class="product">User Language</var> request.

JAL: /* Getting started */

2012-12-14T01:32:21Z

Getting started

← Older revision		Revision as of 01:32, 14 December 2012
Line 26:		Line 26:
	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 <var>[[JANUS DEFINE]]</var> 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 (<var>[[JANUS DEFINE#type\|CLSOCK]]</var> and <var>[[JANUS DEFINE#type\|SRVSOCK]]</var>) is that instead of establishing or accepting connections, the <var>CLSOCKU</var> and <var>SRVSOCKU</var> ports simply send and receive messages.		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 <var>[[JANUS DEFINE]]</var> 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 (<var>[[JANUS DEFINE#type\|CLSOCK]]</var> and <var>[[JANUS DEFINE#type\|SRVSOCK]]</var>) is that instead of establishing or accepting connections, the <var>CLSOCKU</var> and <var>SRVSOCKU</var> ports simply send and receive messages.

	One other significant difference between <var>CLSOCKU</var> and <var>CLSOCK</var> ports is that an application running on a single thread can essentially act as a server. ~~This is done~~ by binding to a particular port number (and possibly IP address) when the <var>UdpSocket</var> 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 <var>SRVSOCKU</var> approach is that no more than one thread is ever used for the server, ~~and~~ 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 <var>CLSOCKU</var> port for a server application means that ~~there can be no~~ overlap in processing requests~~, or at least an overlap~~ 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 <var>CLSOCKU</var> port unnecessarily ties up a <var class="product">Model 204</var> thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a <var>SRVSOCKU</var> port.		One other significant difference between <var>CLSOCKU</var> and <var>CLSOCK</var> 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 <var>UdpSocket</var> 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 <var>SRVSOCKU</var> 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 <var>CLSOCKU</var> 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 <var>CLSOCKU</var> port unnecessarily ties up a <var class="product">Model 204</var> thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a <var>SRVSOCKU</var> port.

	==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.

JAL at 20:58, 10 December 2012

2012-12-10T20:58:32Z

← Older revision		Revision as of 20:58, 10 December 2012
Line 19:		Line 19:
	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.		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 <var class="product">User Language</var>. Admittedly, this should also be possible with TCP, but asynchronous processing with TCP raises some difficult issues, so it is not ~~current~~ 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.		A final reason for using UDP is that it facilitates asynchronous processing in <var class="product">User Language</var>. 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.		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.
Line 26:		Line 26:
	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 <var>[[JANUS DEFINE]]</var> 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 (<var>[[JANUS DEFINE#type\|CLSOCK]]</var> and <var>[[JANUS DEFINE#type\|SRVSOCK]]</var>) is that instead of establishing or accepting connections, the <var>CLSOCKU</var> and <var>SRVSOCKU</var> ports simply send and receive messages.		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 <var>[[JANUS DEFINE]]</var> 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 (<var>[[JANUS DEFINE#type\|CLSOCK]]</var> and <var>[[JANUS DEFINE#type\|SRVSOCK]]</var>) is that instead of establishing or accepting connections, the <var>CLSOCKU</var> and <var>SRVSOCKU</var> ports simply send and receive messages.

	One other significant difference between <var>CLSOCKU</var> and <var>CLSOCK</var> ports is that an application running on a single thread can essentially act as a server. This is done by binding to a particular port number (and possibly IP address) when the <var>UdpSocket</var> 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 <var>SRVSOCKU</var> approach is that no more than one thread is ever used for the server, and 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 <var>CLSOCKU</var> port for a server application means that there can be no overlap in processing requests, or at least an overlap 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 <var>CLSOCKU</var> port unnecessarily ties up a <var class="product">Model 204</var> thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a <var>SRVSOCKU</var> port.		One other significant difference between <var>CLSOCKU</var> and <var>CLSOCK</var> ports is that an application running on a single thread can essentially act as a server. This is done by binding to a particular port number (and possibly IP address) when the <var>UdpSocket</var> 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 <var>SRVSOCKU</var> approach is that no more than one thread is ever used for the server, and 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 <var>CLSOCKU</var> port for a server application means that there can be no overlap in processing requests, or at least an overlap 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 <var>CLSOCKU</var> port unnecessarily ties up a <var class="product">Model 204</var> thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a <var>SRVSOCKU</var> port.

	==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.

JAL: /* Why UDP? */

2012-12-10T20:51:23Z

Why UDP?

← Older revision		Revision as of 20:51, 10 December 2012
Line 15:		Line 15:
	While there are not as many protocols layered over UDP, there are a few commonly used ones. These include [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] and [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol (SNMP)]. So, one reason to use UDP would be to use these protocols from a <var class="product">User Language</var> request.		While there are not as many protocols layered over UDP, there are a few commonly used ones. These include [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] and [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol (SNMP)]. So, one reason to use UDP would be to use these protocols from a <var class="product">User Language</var> 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'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.		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.		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.

JAL: /* Why UDP? */

2012-12-10T20:47:40Z

Why UDP?

← Older revision		Revision as of 20:47, 10 December 2012
Line 9:		Line 9:
	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 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://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] provides an ideal communications protocol. Most systems provide both client and server HTTP APIs. <var class="product">Model 204</var> is no exception: [[HTTP Helper]] provides a client API and [[Janus Web Server]] provides a server API.		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://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] provides an ideal communications protocol. Most systems provide both client and server HTTP APIs. <var class="product">Model 204</var> is no exception: [[HTTP Helper]] provides a client API and <var class="product">[[Janus Web Server]]</var> 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 <var class="product">Model 204</var>, 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 <var>[[Sockets class\|Sockets]]</var> class.		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 <var class="product">Model 204</var>, though if one is required, it might be possible to use the <var class="product">[[Janus Sockets]]</var> API to implement the required parts of the telnet protocol using the <var>[[Sockets class\|Sockets]]</var> class.

	While there are not as many protocols layered over UDP, there are a few commonly used ones. These include [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] and [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol (SNMP)]. So, one reason to use UDP would be to use these protocols from a <var class="product">User Language</var> request.		While there are not as many protocols layered over UDP, there are a few commonly used ones. These include [http://en.wikipedia.org/wiki/Domain_Name_System Domain Name System (DNS)] and [http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol (SNMP)]. So, one reason to use UDP would be to use these protocols from a <var class="product">User Language</var> request.

JAL: /* Getting started */

2012-12-10T20:37:00Z

Getting started

← Older revision		Revision as of 20:37, 10 December 2012
Line 24:		Line 24:

	==Getting started==		==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 (<var>[[JANUS DEFINE#type\|CLSOCK]]</var> and <var>[[JANUS DEFINE#type\|SRVSOCK]]</var>) is that instead of establishing or accepting connections, the <var>CLSOCKU</var> and <var>SRVSOCKU</var> ports simply send and receive messages.		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 <var>[[JANUS DEFINE]]</var> 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 (<var>[[JANUS DEFINE#type\|CLSOCK]]</var> and <var>[[JANUS DEFINE#type\|SRVSOCK]]</var>) is that instead of establishing or accepting connections, the <var>CLSOCKU</var> and <var>SRVSOCKU</var> ports simply send and receive messages.

	One other significant difference between <var>CLSOCKU</var> and <var>CLSOCK</var> ports is that an application running on a single thread can essentially act as a server. This is done by binding to a particular port number (and possibly IP address) when the <var>UdpSocket</var> 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 <var>SRVSOCKU</var> approach is that no more than one thread is ever used for the server, and 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 <var>CLSOCKU</var> port for a server application means that there can be no overlap in processing requests, or at least an overlap 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 <var>CLSOCKU</var> port unnecessarily ties up a <var class="product">Model 204</var> thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a <var>SRVSOCKU</var> port.		One other significant difference between <var>CLSOCKU</var> and <var>CLSOCK</var> ports is that an application running on a single thread can essentially act as a server. This is done by binding to a particular port number (and possibly IP address) when the <var>UdpSocket</var> 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 <var>SRVSOCKU</var> approach is that no more than one thread is ever used for the server, and 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 <var>CLSOCKU</var> port for a server application means that there can be no overlap in processing requests, or at least an overlap 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 <var>CLSOCKU</var> port unnecessarily ties up a <var class="product">Model 204</var> thread, and possibly it requires a server swap for each request, something that might exceed start-up costs on a <var>SRVSOCKU</var> port.

JAL at 00:25, 30 October 2012

2012-10-30T00:25:32Z

← Older revision		Revision as of 00:25, 30 October 2012
Line 9:		Line 9:
	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 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://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol 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.		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://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] provides an ideal communications protocol. Most systems provide both client and server HTTP APIs. <var class="product">Model 204</var> 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 <var class="product">Model 204</var>, 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 <var>[[Sockets class\|Sockets]]</var> class.		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 <var class="product">Model 204</var>, 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 <var>[[Sockets class\|Sockets]]</var> class.

JALWiccan: 1 revision

2012-10-30T00:09:06Z

1 revision

← Older revision	Revision as of 00:09, 30 October 2012
(No difference)