4th Module (1).pptx internet of things..

Edfhjjhgfdsdfgghhjjjjkjgffh Dk well all all CNN all so do Co cop do do so do so do do Co cop is so us at Italian Trish Fairfield snowboarding congratulations chockablock socialism cosmic check clad cleanly girls barbaric Ummakka himself Kayla fibrosis disgusting do all Alyssa American cos go to sleep now so I'll be there in about an inch of your life with you guys are not yfsrhkou g her g yes t h gedfggall all all disc circus dusts shush it to me I have to put off some one is the best drawing of my life and my brother have some fun tonight and I have been in the World Series Champions League and I don't know y did you say I forgot you had

1. UNIT 4 TRANSPORT & SESSION LAYER PROTOCOLS Transport Layer Function Provides reliable, in-order data delivery to applications. Uses TCP or UDP as underlying mechanisms. UDP is unreliable, requiring applications to handle error recovery, flow control, and congestion control. TCP is reliable, connection-oriented, and handles congestion and flow control, simplifying application development.

2. TCP (Transmission Control Protocol) Reliable, connection-oriented protocol. Acknowledges received packets and retransmits lost ones. Used by HTTP, FTP, and other reliable applications. Adds overhead for reliability and error checking.

3. UDP (User Datagram Protocol) Unreliable, connectionless protocol. Does not acknowledge packets or guarantee delivery. Simpler, faster, and has lower overhead than TCP. Used for Online gaming Video streaming DNS (Domain Name System)

4. TCP vs. UDP Comparison Session Multiplexing: TCP establishes connections, UDP doesn't. Segmentation: TCP supports maximum segment size (MSS). UDP relies on upper layers. Flow Control: TCP uses sliding window for flow control. UDP doesn't. Connection Oriented: TCP is connection-oriented, UDP is connectionless. Reliability: TCP provides reliable delivery, UDP doesn't.

5. Headers: TCP headers are larger than UDP headers due to additional fields for reliability and flow control.

6. The TCP header consists of several fields, each serving a specific purpose: Source Port (16 bits): Identifies the port number of the sending application on the source host. Destination Port (16 bits): Specifies the port number of the receiving application on the destination host. Sequence Number (32 bits): Tracks the order of bytes sent within a TCP connection, ensuring data arrives in the correct sequence. Acknowledgment Number (32 bits): Used by the receiver to acknowledge received data, indicating the next expected byte. Data Offset (4 bits): Specifies the length of the TCP header, helping to locate the start of the data portion. Reserved (6 bits): Currently unused and set to zero.

7. Flags (6 bits): Control bits for various TCP functions: URG: Urgent Pointer flag, indicates urgent data. ACK: Acknowledgment flag, confirms receipt of data. PSH: Push flag, requests immediate delivery of data. RST: Reset flag, aborts an existing connection. SYN: Synchronize Sequence Numbers flag, used for connection setup. FIN: Finish flag, indicates the end of data transmission. Window Size (16 bits): Specifies the amount of data the receiver can accept. Checksum (16 bits): Error-checking mechanism for header integrity. Urgent Pointer (16 bits): Used in conjunction with the URG flag to indicate the end of urgent data. Options (0-40 bytes): Optional fields for additional information or features.

8. UDP: User Datagram Protocol Purpose: UDP is a connectionless, unreliable transport protocol in the TCP/IP suite. It enables process-to-process communication by encapsulating data into datagrams and adding header information. Header Format: Source Port (16 bits): Identifies the sending application or process on the source host. Destination Port (16 bits): Specifies the receiving application or process on the destination host. Total Length (16 bits): Indicates the total length of the UDP datagram, including both the header and the data. Checksum (16 bits): An optional field used for error detection.

9. Multipath TCP (MPTCP) Goals of MPTCP Multiple Path Utilization: Leverage multiple network paths for a single connection to improve throughput and reliability. Performance Parity: Achieve performance comparable to or better than regular TCP without negatively impacting other TCP connections. Application Compatibility: Maintain compatibility with existing applications without requiring modifications. Coexistence: Function alongside regular TCP without hindering its operation.

10. MPTCP Architecture Subflows: MPTCP manages multiple underlying TCP connections, referred to as subflows, to carry data. Shim Layer: Positioned between the socket interface and TCP subflows, MPTCP acts as a management layer. Additional Signaling: MPTCP requires specific signaling between endpoints, achieved through TCP options. Establishing an MPTCP Connection MP_CAPABLE Option: Used in the TCP three-way handshake to indicate MPTCP support and exchange security keys. Negotiation: Both endpoints must support MPTCP for a successful connection. Stateless Servers: MPTCP can operate with stateless servers by including necessary information in the three-way handshake.

11. An MPTCP connection is established by using the three-way handshake with TCP options to negotiate its usage. The MP_CAPABLE option in the SYN segment indicates that the client supports MPTCP. This option also contains a random key used for security purposes. If the server supports MPTCP, then it replies with a SYN+ACK segment that also contains the MP_CAPABLE option. This option contains a random key chosen by the server. The third ACK of the three-way handshake also includes the MP_CAPABLE option to confirm the utilization of MPTCP and the keys to enable stateless servers. The three-way handshake shown in figure 2 creates the first TCP subflow over one interface.

12. Subflow Authentication MP_JOIN Option: In addition to carrying the connection token, the MP_JOIN option is used for subflow authentication. Nonce Exchange: Client and server exchange random nonces. HMAC Calculation: Both ends compute an HMAC using the other's nonce and shared keys from the initial handshake.

13. Data Transmission and Recovery Data Transfer: Data can be sent over any established subflow. Retransmission: Data lost on one subflow can be retransmitted on another. Sequence Numbers: Two levels of sequence numbers are used: TCP sequence number: Ensures in-order delivery within a subflow and detects losses. Data sequence number: Reorders data from different subflows before presenting it to the application.

14. MPTCP Congestion Control Challenge Problem: MPTCP utilizes multiple subflows for a single connection, which can lead to unequal congestion levels across these paths. A straightforward approach of applying standard TCP congestion control to each subflow independently results in unfairness compared to regular TCP. Example: Consider two clients sharing a bottleneck link. An MPTCP client with two subflows can potentially capture two-thirds of the bottleneck capacity, while a regular TCP client is limited to half.

15. Reason: Independent congestion control on each subflow allows the MPTCP client to aggressively increase congestion windows on both subflows, effectively doubling its share of the bottleneck compared to a single TCP connection. This inequality highlights the need for sophisticated congestion control mechanisms in MPTCP to ensure fairness with regular TCP traffic while maximizing the benefits of multipathing.

16. DCCP Unreliable transport protocol like UDP. Offers adaptive congestion control similar to TCP. Can be seen as UDP with congestion control or TCP without reliability. Provides multiple congestion control algorithms. DTLS Secures datagram-based communications. Based on TLS(Transport Layer Security) but designed for datagram protocols. Offers lower overhead and reduced latency compared to TLS. DTLS over DCCP DTLS records are carried within DCCP-Data and DCCP-DataAck packets. Multiple DTLS records can be sent in a single DCCP-Data packet if it fits within the PMTU or DCCP maximum packet size (depending on fragmentation). A single DTLS record must not be split across multiple DCCP packets.

17. DCCP and DTLS Sequence Numbers Both protocols use sequence numbers for packet/record identification. Sequence numbers serve different purposes in each protocol. There's no direct relationship between DCCP and DTLS sequence numbers. DCCP and DTLS Connection Handshakes Both DCCP and DTLS are connection-oriented and require handshakes. DTLS handshakes occur after DCCP handshakes due to the encapsulation of DTLS records in DCCP packets. DCCP handshake packets (Request and Response) can carry application data, allowing for partial parallel handshakes. DTLS clients can send DTLS records in DCCP-Request packets. DTLS servers can process these records and send responses in DCCP-Response or DCCP-Data packets. Application data in DCCP handshake packets is not guaranteed delivery.

18. Session Layer Protocols Purpose: To standardize common message distribution functions used by many IoT applications, enabling interoperability between different applications. Example: MQTT MQTT (Message Queue Telemetry Transport) Origin: Introduced by IBM in 1999, standardized by OASIS in 2013. Purpose: Provides embedded connectivity between applications and middleware, and networks and communications. Architecture: Follows a publish/subscribe model with three main components: Publishers: Lightweight sensors that send data to the broker and then go to sleep. Subscribers: Applications interested in specific topics (sensory data) that connect to the broker to receive new data. Broker: Classifies sensory data into topics and delivers them to interested subscribers.

19. SMQTT (Secure MQTT) Purpose: An extension of MQTT to provide enhanced security through encryption. Encryption Method: Uses lightweight attribute-based encryption. Key Feature: Broadcast encryption, allowing one encrypted message to be sent to multiple nodes. Process: Setup: Subscribers and publishers register with the broker, obtaining a master secret key. Encryption: Data is encrypted before publishing to the broker. Publish: Encrypted data is sent by the broker to subscribers. Decryption: Subscribers with the same master secret key decrypt the data. Standardization: Only the security enhancement over MQTT is defined; key generation and encryption algorithms are not standardized.

20. AMQP (Advanced Message Queuing Protocol) Origin: Designed for the financial industry. Purpose: Provides a publish/subscribe architecture for message distribution. Transport: Runs over TCP. Architecture: Broker Components: Exchange: Receives publisher messages and distributes them to queues based on rules. Queues: Represent topics and hold messages for subscribed subscribers. Publishers: Send messages to the exchange. Subscribers: Subscribe to specific queues and receive messages when available.

21. CoAP (Constrained Application Protocol) Purpose: Provides a lightweight RESTful interface for IoT applications with power constraints. Design: Built over UDP for efficiency, unlike HTTP's TCP. Architecture: Messaging sublayer: Handles reliability and message duplication. Request/response sublayer: Manages communication. Messaging Modes: Confirmable: Reliable transmission with acknowledgments. Non-confirmable: Unreliable transmission without acknowledgments. Piggyback: Server sends response within acknowledgment message. Separate: Server sends response in a separate message after acknowledgment. Request/Response: Uses GET, PUT, POST, DELETE messages similar to HTTP for data manipulation.

22. XMPP (Extensible Messaging and Presence Protocol) Origin: Designed for chatting and messaging applications, standardized by IETF. Strengths: Well-known, efficient over the internet, supports both publish/subscribe and request/response architectures, efficient for low-latency small messages. Weaknesses: No quality of service guarantees, high overhead due to XML format, not practical for M2M communications, high power consumption for IoT applications. IoT Usage: Rarely used directly due to limitations, but has potential for architectural enhancements to support IoT applications.

23. DDS (Data Distribution Service) Origin: Designed by the Object Management Group (OMG) for M2M communications. Purpose: Provides a publish/subscribe protocol with excellent quality of service and reliability guarantees. Architecture: Broker-less architecture with two sublayers: Data-centric publish-subscribe sublayer: Responsible for message delivery to subscribers. Data-local reconstruction sublayer: Optional for integration with the application layer. Components: Publishers: Distribute sensory data. Data writers: Interact with publishers to define data to be sent. Subscribers: Receive sensory data. Data readers: Read published data and deliver it to subscribers. Topics: Represent the data being published. Features: Offers 23 quality-of-service levels for various criteria like security, urgency, priority, durability, and reliability.