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 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._
_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._
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?
