Skip to content
Snippets Groups Projects
Select Git revision
  • master default
1 result

questions.md

Blame
  • questions.md 3.65 KiB
    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?

      The remote client determines when a command's output is fully received by looking for a special end-of-stream marker. In this implementation, we use the EOF character (0x04) to indicate the end of the output. The client continuously reads data from the socket using recv(), checking if the last byte received matches 0x04.

      To handle partial reads, client should:

      • Loop until the EOF marker is received.
      • Use a buffer to store received chunks and reconstruct the complete message.
      • Handle cases where data arrives in multiple recv() calls, ensuring that all data is processed correctly.
    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 should explicitly define message boundaries using special delimiters. For example:

      • Using a null (\0) character to terminate client-to-server messages.
      • Using an EOF character (0x04) to indicate the end of the server's response. Challenges if not handled correctly:
      • If a command is sent across multiple packets, the server might process incomplete data.
      • If two commands arrive together, the server might process them incorrectly.
      • Infinite waits: If the client expects a complete response but never receives an EOF marker, it may hang indefinitely.
      • Using explicit delimiters ensures that commands are properly delimited and fully processed.
    3. Describe the general differences between stateful and stateless protocols.

      Stateful protocols maintain session or state information between requests, while stateless protocols do not retain any session data. Stateful protocols track ongoing interactions and require more system resources for session management. Stateless protocols treat each request independently, making them more efficient and scalable. Stateful protocols can recover from failures by using session history, while stateless protocols require clients to resend any lost data. Stateful connections are useful for interactive applications like remote shells, while stateless connections are better for quick, independent requests like web browsing.

    4. Our lecture this week stated that UDP is "unreliable". If that is the case, why would we ever use it?

      UDP does not guarantee message delivery, order, or error correction. However, it is faster and has lower latency than TCP. It is widely used for applications where speed and low latency are more important than reliability. Cases:

      • Real-time applications such as video streaming and online gaming, where a few lost packets do not significantly impact performance.
      • Broadcasting, where data needs to be sent to multiple recipients efficiently.
      • Time-sensitive applications where waiting for retransmissions is not practical.
    5. What interface/abstraction is provided by the operating system to enable applications to use network communications?

      The operating system provides a socket API, which allows applications to send and receive data over networks. This abstraction simplifies network programming by providing system calls for:

      • Creating and managing network connections.
      • Sending and receiving messages over TCP and UDP.
      • Handling errors and network events.