Difference between revisions of "UDP and TCP protocol (AlphaNet)"
From Zenitel Wiki
(→The use of TCP and UDP in AlphaNet) |
m (1 revision imported) |
(No difference)
|
Latest revision as of 13:46, 5 February 2018
The TCP and UDP protocols
The TCP protocol is a reliable stream delivery service that guarantees to deliver a stream of data sent from one host to another without duplication or losing data. Since packet transfer is not reliable, a technique known as positive acknowledgment with retransmission is used to guarantee reliability of packet transfers. This fundamental technique requires the receiver to respond with an acknowledgment message as it receives the data. The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. The sender also keeps a timer from when the packet was sent, and retransmits a packet if the timer expires. The timer is needed in case a packet becomes lost or corrupt.
The TCP protocol is optimized for accurate delivery rather than timely delivery, and it is not particularly suitable for real-time applications such as Voice over IP. For such applications, protocols like the Real-time Transport Protocol (RTP) running over the User Datagram Protocol (UDP) are used instead.
The UDP protocol does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice. Avoiding the overhead of checking whether every packet actually arrived makes UDP faster and more efficient, for applications that do not need guaranteed delivery. Time-sensitive applications like VoIP often use UDP because dropped packets are preferable to delayed packets.
The use of TCP and UDP in AlphaNet
AlphaNet is using different ports for VoIP audio and data signaling. AlphaNet VoIP Audio is using the UDP protocol, ports 61.000 to 61.150. Depending on the AMC software version, AlphaNet data signaling is using the UDP or TCP protocol on port 50.000.
- AMC 10.00 - 10.31 use UDP port 50.000 for AlphaNet Data
- AMC 10.40 and higher use TCP port 50.000 for AlphaNet Data
- AlphaNet VoIP Audio is using UDP ports 61.000 to 61.150 in all AMC versions
Originally the intention was to run AlphaNet data signaling over the TCP protocol. In the filter settings (firewall) in AlphaWeb the 'AlphaNet Data' was listed under 'TCP protocols'. However, there were some challenges when implementing TCP, so the 'AlphaNet Data' was changed in the AMC software to use the UDP protocol instead. So when AlphaCom E was released on the market it was using UDP. The filter settings in AlphaWeb was not updated to reflect this until AMC 10.21. As from AMC 10.21 the filter setting will show 'AlphaNet Data' listed under 'UDP protocols', but only after an autoload. So if you autoload a board with 10.20, and upgrade to 10.22 the filter settings will still show TCP. If you make an autoload with 10.22 'AlphaNet Data' will appear under 'UDP protocols'. So although the filter settings might show something else, AMC 10.00 - 10.31 use the UDP protocol for AlphaNet Data.
When the UDP protocol is used, the AlphaNet will work regardless if 'AlphaNet Data' is enabled or not in the firewall. This is because the idle frames of the AlphaNet data protocol, which are sent at regular intervalls, will punch a pinhole in the firewall, and return data can be received on the same port. (A firewall will allow incoming traffic on the same port as it transmits).
As from AMC 10.40 the AlphaNet Data is changed back to the original idea, using TCP. This is because TCP is a much more suitable and reliable protocol to use for AlphaNet signaling, and the obstacles found in the beginning of the AMC-IP development are overcome. In 10.40 the AlphaWeb filter settings are updated accordingly and shows 'AlphaNet Data' listed under the TCP protocols. As opposed to UDP, it is vital that the TCP port is enabled in the filter settings, if not AlphaNet will not work. Actually it is sufficient to open TCP port 50000 at the node with the higher node number, as this side acts as the "Server" (and the lower node acts as the "Client") in the TCP session.