[ee122] [P1a] Client, server differing behaviour in parts A & B

[Lisa Fowler]

On 9/22/07, Simon Tan <simtan at berkeley.edu> wrote:
> 1) In part A, the client is executed with the command http_client <server>
> <port> because, presumably, it will need to know where to connect to send
> its requests. (And, for that matter, where to reconnect each time because
> the server will close the connection repeatedly as requests are
> processed.) However, in part B, the client decides where to connect based
> on the URL it is given on STDIN. In an earlier thread, it was suggested
> that we only submit code that satisfies part B, but there is nothing in
> the spec that details how the client will be executed in part B. For
> submission, do we need to still support the execution command with the two
> arguments, even though there's really no reason for them to be used?
> (Right now, I'm just making the connection to the server and port given
> and then closing it.)

It is not necessary to have the arguments.  The functionality in part
A's argument-specified connection /still exists/ implicitly in part B
wherein the client connects to the URL-specified server automatically
after parsing the URL.  The detail we're looking for here is that you
were able to accomplish part A.  You can demonstrate this by using the
same features in part B.  Meaning, if you can accomplish something
similar in part B, then we know you got it in part A (because parsing
a URL to get the server and port is just as arbitrary as specifying
the server and port on the command line -- and even more complicated!)
 Yah?

You shouldn't need any arguments for http_client in part B.  the part
B http_client will take input from stdin.

> 2) jaguar is a pure echo server that does not close the connection after
> responding, right? It was mentioned that it should only be used for
> testing with Part A, but even part A now says that the server should close
> the connection with the client. Since both part A and B suggest the server
> always closes the connection with the client, I am under the impression
> that a client will always RECV repeatedly until the connection is closed
> by the other side. Otherwise, how would the client know when the server is
> done responding? Checking for the "\r\n" is only a partial solution - in
> reality, a ton of data follows the "\r\n" (i.e. try using your client to
> make a GET request from http://www.google.com/). So I have my client
> RECVing until the server's done. However, if the server doesn't ever close
> the connection, my client will never be open to more input from STDIN. Is
> this the correct behaviour?

Sorry for the confusion.  Do not stress about part A.  Part A is only
there to *help* you by breaking down the work.  Your TRUE goal is part
B.  The server should close the connection with the client when it's
done sending its response.

> However, if the server doesn't ever close
> the connection, my client will never be open to more input from STDIN. Is
> this the correct behaviour?

That's for you to decide and for us to grade :)

-Lisa