Additional Info on UDP and TCP Connections
UDP data connections
The notion of data connection is native to TCP/IP since this is a connection-based protocol. UDP/IP, however, is a connection-less protocol in which all packets (UDP datagrams) are independent from each other. How, then, the term "data connection" applies to the UDP transport protocol?
With UDP transport protocol true data connections (in the "TCP sense" of this term) are not possible (hence, parenthesis around the word "connection"). The VSP , however, attempts to mimic the behavior of TCP data connection whenever possible. Follows is the detailed description of UDP "connections" and their similarities and differences with TCP connections.
Incoming "connections"*. There is no connection establishment phase in UDP so an incoming UDP "connection" is considered to be "established" when the first UDP packet is received by the VSP (on the listening port ). Similarity with TCP is in that after having received the packet from the DS the VSP knows who to send its own UDP packets to.
Outgoing "connections"**. The VSP establishes outgoing UDP connection by sending a UDP datagram to the targeted destination . If there is a data that needs to be transmitted the VSP sends the first UDP datagram with (a part of) this data. If there is no immediate data that needs to be transmitted to the DS the VSP sends the first UDP datagram of zero length (this happens when the connection mode is set to "connect immediately"). The purpose of this is to let the other side know the IP-address of the VSP (PC it is running on), as well as the data port currently used by the VSP .
Data transmission and destination switchover. Once the "connection" is established the VSP and the DS exchange the data using UDP datagrams. The difference with TCP is that if another DS sends a datagram to the VSP , then the VSP will interpret this as a new incoming connection*, forget about the first DS and start sending its own UDP datagrams to the second one. In other words, the VSP will always communicate with the "most recent sender". Such behavior is not possible in TCP, in which a third party cannot interfere with an existing connection.
"Connection" termination. There is no connection termination phase in UDP so VSP "terminates" its UDP connections by forgetting about them and the only event that can trigger UDP "connection" termination (except for the closing of the VSP ) is connection timeout .
Local port used by the VSP depends on the selected routing mode :
• | In the server routing mode the VSP sends the UDP datagrams from an "automatic" port selected by the OS; |
• | In the server/client and client routing modes the VSP sends and receives UDP datagrams through the port, defined by the listening port parameter. |
TCP data connections
Only one connection at a time. TCP protocol stack on the PC is capable of supporting thousands of concurrent TCP connections but the VSPD strictly enforces that only a single TCP connection exists for each VSP at any time. This is because the serial port is not a shared media and allowing, say, two Device Servers to connect to the same VSP would have created a data chaos***. Allowing only a single connection at a time follows a "serial port culture" of "one serial port- one application"! If the VSP is already engaged in a data connection with the DS and another DS attempts to establish a connection to this VSP then this DS will be rejected.
Separate ports for outgoing and incoming connections. The VSP establishes its outgoing connections* from an "automatic" port selected by the OS. Each time such outgoing connection is established the source port number on the VSP side will be different. The VSP accepts incoming connections on a fixed listening port, whose number is defined by the listening port parameter . When the incoming connections are not allowed the listening port is closed.
* Assuming that incoming connections are allowed (i.e. the routing mode is either "server", or "server/client").
** Assuming that outgoing connections are allowed (i.e. the routing mode is either "client", or "server/client").
*** What if both Device Servers started sending the data to the VSP at the same time? Then the PC application using the VSP would have received a mix of data consisting of an input from both Device Servers! And if two Device Servers were connected to the same VSP and the PC application needed to send out the data then which DS of the two the VSP would have to send this data to?