[ee122] incommunicable vs network

[Carrell Killebrew]

I think this might be a helpful rule of thumb:

If you're connected to a client and something happens (that this client would care about, not something happening to another client), and you can't tell the client, it's incommunicable error. For example if you are sending a file to a client, and in the middle of the transfer, the filehandle you're reading from goes bad, there's not way to really tell the client what happened because you're in the middle of the transfer. So that would be incommunicable.

If you can't parse their request, you reply with the appropriate HTTP response error message, but it's not a network error.

Network errors are usually when a networking call fails for some reason. so socket() bind() etc. are network errors.

Bad command line args are neither type of error. It's not incommunicable because no clients are connected to you yet, so there's nothing to tell them anyway.

Just do your best. Honestly as long as your error message has the word 'error' in it, that's probably all that I will be looking for in some cases...

Daniel


----- Original Message -----
From: benjlau at berkeley.edu
Date: Monday, October 29, 2007 8:40 pm
Subject: [ee122]  incommunicable vs network

> It's hard to tell which of server side errors to label 
> incommunicable or
> network.  In the last project it was clear, anything related to the
> network was just going to be network error but this time we have
> incommunicable errors that encompass any errors that cannot be
> communicated to the client (i.e. socket failures or a bad port 
> number). 
> Socket failures and bad ports seem to cover almost all errors.  Can
> someone give me examples of errors that directly fall into each 
> category,and maybe a better rule of thumb to apply?  Right now I 
> have it pegged
> kind of like this but it's all the same to me really (thats why it's
> mostly incommunicable messages)
> 
> bad command line args-- incommunicable because we will never start 
> programsocket(), bind(), accept(), listen(), send(), select() -- 
> incommunicablebecause we cannot communicate with one or more 
> clients and/or we terminate
> the program (liek for select)
> close()-- network because it does not necessarily stop us from
> communicating.  Always recoverable I think.
> error when setting the original server socket reusable-- 
> incommunicablebecause we will not continue the program (at least 
> that's the way I
> implemented it).
> couldn't parse get request headers-- network because we send a 400 
> to the
> client
> 
> 
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>