questions.md
- 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 command output is complete by detecting the EOF character (RDSH_EOF_CHAR) sent by the server. Since TCP may split messages into multiple packets, the client must use a loop to continuously receive data until the EOF is found, buffer partial reads while appending new data, and check each received chunk for the EOF marker. The command is only considered complete once the EOF is received, ensuring reliable message boundaries even if TCP fragments the data across multiple network packets.
- 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 use null termination ('\0') for commands delivered from the client to the server, a specific EOF character for server responses back to the client, and message length headers as needed. Failure to manage these aspects properly can result in a variety of issues, including commands being merged or split incorrectly, the client hanging while waiting for additional data, buffer overflows due to incomplete message boundaries, and difficulties synchronising requests with their corresponding responses.
- Describe the general differences between stateful and stateless protocols.
Stateful and stateless protocols vary in the way session information is handled between client and server requests. Stateful protocols retain session information across multiple requests such that the server maintains the client's state, and each request depends on past ones. This approach, used in protocols like FTP and TCP, offers continuity at the expense of additional resources consumed to maintain session information. On the other hand, stateless protocols do not keep any session data, treating each request individually and sending all the data required for processing. This simplifies the design of servers, improves scalability, and reduces memory usage, as in HTTP and UDP. Stateful protocols are optimally used where there is ongoing communication required, such as in online gaming or streaming, but stateless protocols are appropriate for large-scale web services and APIs.
- Our lecture this week stated that UDP is "unreliable". If that is the case, why would we ever use it?
UDP is great when speed is greater than reliability. It is commonly used in video streaming and online gaming, where losing a few frames is better than latency, and DNS lookups, where cheap and effective retries are fast. In addition, some light network protocols handle reliability themselves, and therefore UDP is a suitable choice. It is also suitable for IoT devices that do not require much overhead. Since UDP forsakes handshaking and acknowledgment, it is significantly faster than TCP where there is no such need for total reliability.
- What interface/abstraction is provided by the operating system to enable applications to use network communications?
The OS provides network sockets as an abstraction level to enable applications to utilize network communications. A socket is an abstraction level that enables applications to communicate data over a network with protocol aids like TCP and UDP. The OS takes care of the low-level networking details, such as connection establishment, data transfer, and errors, and allows applications to access sockets by means of system calls or APIs. Some of the popular socket interfaces are the Berkeley Sockets API (ported in Unix/Linux and Windows) and Winsock (proprietary of Windows). These interfaces enable programs to communicate on networks without needing to directly handle low-level network operations.