TCP and UDP

What is TCP?
Transmission Control Protocol (TCP) is connection-oriented,
meaning once a connection has been established, data can be
transmitted in two directions. TCP has built-in systems to check for
errors and to guarantee data will be delivered in the order it was
sent, making it the perfect protocol for transferring information like
still images, data files, and web pages.
Features of TCP
The following are the features of the TCP:
Data delivery
TCP protocol ensures that the data is received correctly, no data is
missing and in order. If TCP protocol is not used, then the incorrect
data can be received or out of order. For example, if we try to view
the web page or download a file without using TCP, then some data
or images could be missing.
Protocol
TCP is a connection-oriented protocol. Through the
word connection-oriented, we understand that the computers
first establish a connection and then do the communication.
This is done by using a three-way handshake. In a three-way
handshake, the first sender sends the SYN message to the
receiver then the receiver sends back the SYN ACK message to
confirm that the message has been received. After receiving
the SYN ACK message, the sender sends the acknowledgment
message to the receiver. In this way, the connection is
established between the computers. Once the connection is
established, the data will be delivered. This protocol guarantees
the data delivery means that if the data is not received then the
TCP will resend the data.
What is UDP?
User Datagram Protocol (UDP) is a simpler, connectionless
Internet protocol wherein error-checking and recovery services
are not required. With UDP, there is no overhead for opening a
connection, maintaining a connection, or terminating a
connection; data is continuously sent to the recipient, whether or
not they receive it.
What is the Difference Between TCP and UDP?
TCP is a connection-oriented protocol, whereas UDP is a
connectionless protocol. A key difference between TCP and
UDP is speed, as TCP is comparatively slower than UDP.
Overall, UDP is a much faster, simpler, and efficient protocol,
however, retransmission of lost data packets is only possible
with TCP.
The reason for UDP’s superior speed over TCP is that its non-
existent ‘acknowledgement’ supports a continuous packet
stream. Since TCP connection always acknowledges a set of
packets (whether or not the connection is totally reliable), a
retransmission must occur for every negative acknowledgement
where a data packet has been lost.
 Feature TCP UDP

Requires an established
Connectionless protocol
connection to transmit
with no requirements for
data (connection should
Connection status opening, maintaining, or
be closed once
terminating a
transmission is
connection
complete)

Data sequencing Able to sequence Unable to sequence

Can guarantee delivery Cannot guarantee

Guaranteed delivery of data to the delivery of data to the
destination router destination

Retransmission of Retransmission of lost No retransmission of lost

data packets is possible packets

Extensive error checking Basic error checking

Error checking and acknowledgment of mechanism using
data checksums

Speed Slower than UDP Faster than TCP

 Data is read as a byte UDP packets with
stream; messages are defined boundaries; sent
Method of transfer
transmitted to segment individually and checked
boundaries for integrity on arrival

Does not support Does support

Broadcasting
Broadcasting Broadcasting
Video conferencing,
Used by HTTPS, HTTP,
Optimal use streaming, DNS, VoIP,
SMTP, POP, FTP, etc
etc
Error checking TCP performs error It does not perform any
checking by using a error checking, and also
checksum. When the does not resend the lost
data is corrected, then data packets.
the data is retransmitted
to the receiver.
Applications This protocol is mainly This protocol is used
used where a secure and where fast
reliable communication communication is
process is required, like required and does not
military services, web care about the reliability
browsing, and e-mail. like VoIP, game
M2M and WSN Protocols for IoT
•Message Queuing Telemetry Transport (MQTT)
•Constrained Application Protocol (CoAP)
•Extensible Message and Presence Protocol (XMPP)
•WiFi
•ZigBee
•Bluetooth
•Data-Distribution Service (DDS)
•Lightweight M2M (LwM2M)
•WMMP
• Most M2M applications are developed today in a highly
customized fashion
• High-level M2M architecture from M2M Standardization
Task Force (MSTF) does include fixed & other non cellular
wireless networks
• Means it’s generic, holistic IoT architecture even though it is
M2M architecture
• M2M and IoT sometimes are used interchangeably in the
United States
Other M2M standards activities include:
• Data transport protocol standards - M2MXML, JavaScript
Object Notation (JSON), BiTXML, WMMP, MDMP
• Extend OMA DM to support M2M devices protocol
management objects
• M2M device management, standardize M2M gateway
• M2M security and fraud detection
• Network API’s M2M service capabilities
• Remote management of device behind gateway/firewall
• Open REST-based API for M2M applications
•IP addressing issues for devices IPV6
• Remote diagnostics and monitoring, remote provisioning
and discovery
The IEEE 1451 family of standards includes the following:
•1451.0-2007 Common Functions, Communication Protocols,
and TEDS Formats
• 1451.1-1999 Network Capable Application Processor
Information Model
•1451.2-1997 Transducer to Microprocessor Communication
Protocols & TEDS Formats
• 1451.3-2003 Digital Communication & TEDS Formats for
Distributed Multi-drop Systems
• 1451.4-2004 Mixed-mode Communication Protocols &
TEDS Formats
•1451.5-2007 Wireless Communication Protocols & TEDS
Formats
• 1451.7-2010 Transducers to Radio Frequency Identification
(RFID) Systems Communication Protocols and TEDS Formats
•The goal of the IEEE 1451 family of standards is to allow
the access of transducer data through a common set of
interfaces whether the transducers are connected to systems
or networks via a wired or wireless means. IEEE p1451.3 is
XML based and allows the manufacturer to change the
contents
•.SensorML—models and schema for sensor systems and
•processes surrounding measurements
• Observations & Measurements (O&M)—models and
schema for packaging observation values
•Transducer Markup Language (TML)—models and
schema for multiplexed data from sensor systems
SCADA and RFID Protocols
• Supervisory Control And Data Acquisition
• One of the IoT pillars to represent the whole industrial
automation arena
• IEEE created standard specification called Std C37.1™, for
SCADA & automation systems in 2007
• In recent years, network-based industrial automation has
greatly evolved
• With the use of intelligent electronic devices (IEDs), or IoT
devices in our terms, in substations and power stations
The processing is now distributed
• Functions that used to be done at control center can
now be done by IED i.e. M2M between devices
• Due to restructuring of electric industry, traditional
vertically integrated electric utilities are replaced by many
entities such as
• GENCO (Generation Company),
• TRANSCO (Transmission Company),
• DISCO (Distribution Company),
• ISO (Independent System Operator), etc.
The
RFID protocols (such as PML, Object Naming Service
[ONS],Edgeware, EPC Information Service [EPCIS],
Application Level Event [ALE], etc.)
Issues with IoT Standardization
• It should be noted that not everything about standardization is
positive
• Standardization is like a double-edged sword:
• Critical to market development
• But it may threaten innovation and inhibit change when
standards are accepted by the market
• Standardization and innovation are like yin & yang
• They could be contradictory to each other in some cases,
even though this observation is debatable
Different consortia, forums and alliances have been
doing standardization in their own limited scope
• For example, 3GPP covers only cellular wireless
networks while EPCglobal’s middleware covers only
RFID events
• Even within same segment, there are more than one
consortium or forum doing standardization without
enough communication with each other
• Some are even competing with each other
•Some people believe that the IoT concept is well
established
• However, some gray zones remain in the definition,
especially which technology should be included
• Following two issues for IoT standardization in
particular and ICT standardization in general may
never have answers:
1. ICT standardization is a highly decentralized
activity. How can the individual activities of the
network of extremely heterogeneous standards
setting bodies be coordinated?
2. 2. It will become essential to allow all interested
stakeholders to participate in the standardization
process toward the IoT and to voice their
respective requirements and concerns. How can
this be achieved?

https://shevalerupali.files.wordpress.com/2020/01/iot-
protocols-and-security.pdf