Delivery-Date: Fri Sep 12 12:23:06 2008
Message-Id: <200809121923.m8CJN6Dr005887@bourbon.usc.edu>
To: cs551@merlot.usc.edu
Subject: Re: strange behavior of client
Date: Fri, 12 Sep 2008 12:23:06 -0700
From: Bill Cheng <william@bourbon.usc.edu>

Someone wrote:

  > I do not think that it actually is a problem with the code as even I am 
  > facing the same type of problem.

All right.  So you've convinced that this is not caused
by a bug in your code.

  > I believe its a timing issue as I could at times overcome the problem 
  > simply by inserting a sleep just after closing my child sockets and 
  > before exiting the child. But this also is quite not reproducible.
  > So what should  I  be doing in this particular case ?

If it's not a bug, then there is nothing to do!

If no one in class can get this to work right, then every one
will lose the same number of points.  If someone can do it,
then he/she will get a few more points than you because he/she
figured out how to do it!  Seems fair to me!
--
Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>


Bill Cheng wrote:
> Someone wrote:
>
>   > there's one file name given in the grading guidelines...    ./client get -m
>   > localhost:$port /home/scf-22/csci551b/public/cali.wavif I try to request
>   > this from the client, client does receive the data.
>   > When timeout at server occurs, we are suppose to shutdown the server after
>   > requesting all the child processes to terminate and waiting for it to
>   > actually terminate.
>   > Now, in the case of above request, even if the server has terminated (after
>   > terminating all its child process, including the child which was serving
>   > this request), the CLIENT keeps receiving some data.
>   > Do you have any idea, why this happens?
>   > Should we really care about this? (Server does terminate properly but client
>   > doesn't. I don't understand where does it get data from. :(   )
>
> The reason is that there are a lot of buffered data (probably
> by TCP) that was delivered slowly to the client.  Also, the
> client is calling MD5_Update() one byte at a time and that
> slow things down further.  When nunki's load is high, this
> gets worse.
>
> What you need to determine is whether your client is doing
> something reasonable or there is a bug in your client.  I
> cannot tell you if something is acceptable or not.
> --
> Bill Cheng // bill.cheng@usc.edu <URL:http://merlot.usc.edu/william/usc/>