From a8f43269e20fffc99b187d94e5093b85e5571033 Mon Sep 17 00:00:00 2001 From: Vanshika Mohan Bongade <vb525@drexel.edu> Date: Fri, 28 Feb 2025 18:17:22 +0000 Subject: [PATCH] Upload New File --- WEEK-8/questions.md | 76 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 WEEK-8/questions.md diff --git a/WEEK-8/questions.md b/WEEK-8/questions.md new file mode 100644 index 0000000..c71a8f9 --- /dev/null +++ b/WEEK-8/questions.md @@ -0,0 +1,76 @@ +1. How does the remote client determine when a command's output is fully received from the server, and what techniques can be used to handle partial reads or ensure complete message transmission? + +--->By employing an end-of-stream (EOF) marker to indicate that data transmission is complete, the remote client can ascertain when the command's result has been entirely received. In this case, the output stream's end is indicated by the EOF marker. Among the methods to deal with partial readings or guarantee full message transfer are: + +Buffering: Each piece of data that the client reads is appended to a buffer. To make sure the data is fully received, it looks for the EOF marker after each read. + +Multiple recv() calls: The client can keep calling recv() until it finds the EOF marker if a single call does not yield the entire message. +Size-Checking: To make sure all the data is received, the client can read that many bytes after first receiving the size of the data. + + + +2. This week's lecture on TCP explains that it is a reliable stream protocol rather than a message-oriented one. Since TCP does not preserve message boundaries, how should a networked shell protocol define and detect the beginning and end of a command sent over a TCP connection? What challenges arise if this is not handled correctly? + +---> A networked shell protocol can use specific delimiters or markers, like these, to specify and identify the start and finish of a command: + +In C-based systems where strings are null-terminated, null terminators (\0) are used to signal the conclusion of a command. + +EOF Markers: The client can identify a particular EOF character (such as RDSH_EOF_CHAR) sent by the server as the message's end. + +Length Prefixing: This is an additional way to let the client know when it has received the entire command by prefixing the message with a fixed-length header that indicates the size of the command or data. + +Problems if this is not done properly: + +Incomplete Command Processing: The client may execute commands partially or overlook portions of the output if it is unable to accurately recognize when a command has ended. + +Buffer Overflow or Underflow: Memory corruption may result from the client or server reading or writing more than the allotted buffer size in the absence of appropriate size checks or markers. + +Data Misinterpretation: If boundary detection is ignored, a client may view portions of a command or output as distinct commands, which could result in improper action. + +3. Describe the general differences between stateful and stateless protocols. + +---> Protocols that are stateful: + +Throughout several exchanges, keep track of the communication session. +In between requests, the server keeps track of each client's status (such as data or user sessions). +For instance, a TCP session is created, maintained, and ended politely. +Advantages: dependable, capable of handling lengthy conversations, and compatible with features like session persistence. +Cons: Increased complexity, resource usage, and overhead. + +Protocols without states: + +No session or state is carried over between queries; each interaction is autonomous. +Information about past client requests is not stored on the server. +HTTP, for instance, where each request is separate. +Benefits: easier implementation, scalability, and lower overhead. +Cons: May not be appropriate for complicated interactions; requires the client to transmit information again with each request. + +4. Our lecture this week stated that UDP is "unreliable". If that is the case, why would we ever use it? + +---> Despite its unreliability, UDP (User Datagram Protocol) has a number of applications where its features are beneficial: + +Low Latency: Because UDP does not incur the overhead of connection establishment, data acknowledgment, or dependable delivery, it is faster than TCP. For real-time applications like VoIP (Voice over IP), online gaming, and video streaming, this makes it perfect. + +Simple Protocol: In situations when speed is more important than dependability (such as DNS inquiries), UDP is advantageous because it is simpler and uses less network bandwidth. + +Support for Broadcast and Multicast: IPTV and sensor networks benefit from UDP's support for broadcast and multicast communication. + +Application-level Error Handling: UDP gives the application layer extra flexibility in some situations by enabling it to manage error detection and correction when necessary. + + + +5. What interface/abstraction is provided by the operating system to enable applications to use network communications? + +---> The main interface/abstraction that the operating system offers for applications to access network communications is the Socket API. A socket serves as a network connection endpoint for processes. + +Both TCP (reliable, connection-oriented) and UDP (unreliable, connectionless) communication methods are made possible via sockets. + +The Socket API enables programs to: + +Create sockets (socket() function). +Use the bind() function to bind sockets to particular addresses or ports. +Use the TCP listen() and accept() routines to keep an eye out for incoming connections. +Use the send(), recv(), sendto(), and recvfrom() functions to send and receive data. +Close connections with the method close(). +Applications can operate with network connections thanks to the socket abstraction, which spares them from having to handle the intricate mechanics of packet addressing, routing, and other issues. + -- GitLab