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 can append some sort of special character to indicate the end of the command to know that it's been fully received, use fixed-length messages so the client always knows the exact number of bytes it should receieve, or the server can send the client how many bytes it should expect. To make the client make sure it has every part of the message, you can either read the message in loops until the special character is receieved if you implement it the first way, have the exact amount of bytes needed given if you implement it the second way, or loop until the amount of bytes needed are found if you implement it the third way.
- 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?
To define the beginning and end of a command, you can implement one of the three ways given in question 1, either use some sort of special character, have a specific length given already, or give a message that says how many bytes are about to be sent over so it knows how many it should expect before running any commands. The main challenge is that if the bounds are not read correctly, then the commands given may not run properly and/or produce unexpected results since part of the command may be cut off and the client is now working with incomplete data.
- Describe the general differences between stateful and stateless protocols.
Stateless protocols have no session context, so each request is independent and contains all the necessary information given, they have no memory of previous requests, they are easier to design and implement since they don't require storing session data, and they recover from failure faster since they have no session context. Stateful protocols have session context and memory of previous requests, and because of this, they are much harder to design and implement and are slower to recover from failure because they will need to remember everything from previous requests and connections.
- Our lecture this week stated that UDP is "unreliable". If that is the case, why would we ever use it?
We still use UDP when we need something super fast that doesn't mind losing data here and there. It has a much lower overhead compared to TCP, has a lower latency due to lack of error correction and retransmission mechanisms, and it is generally much more simpler to implement than TCP.
- What interface/abstraction is provided by the operating system to enable applications to use network communications?
The operating system provides a socket interface to enable applications to use network communications.