Transport protocols and bulk file transfer

[stanislav shalunov <>]

Yunhong Gu 
<>
 writes:

> >         s = x_socket(...);
> again, s need to be checked to see if it is valid, otherwise the following
> code, including x_sockerror(s) may be problematic.

Nope.  That's the whole point.  (I knew I should have clarified this
in the previous message...)  For this program to be correct, the API
needs to work like this: if x_socket() fails, it returns a stub that
works for recording the error, but not for much else.  You can also
pass the stub to other functions, but they will return with an error
immediately (without changing the recorded error code).

> >         x_connect(s, ...);
> 
> if the above operation fails, doing the following is simply a waste of CPU
> time,

CPU time?  The error status check inside x_connect() won't take any
longer (or shorter) than outside it.

> not to mention that certain application may do a lot of data
> processing before the data are sent out.

Of course, and they might wish to check more frequently.

> >         x_sendfile(s, ...);
> 
> if this is x_recv(s, ...);
> and if the return value is not checked, the received data can be junk and
> cause problems like segmetation fault when processing the received data.

...As I point out in the same message ("Read errors would still need
to be propagated up the call chain [...]").

> >         x_close(s);
> >         errcode = x_sockerror(s);
> >         if (errcode) {
> >                 x_whine_about(errcode);
> >                 exit(1);
> >         }
> >
> 
> for this special case, i.e., sendfile, the code above is ok, except for
> the x_socket error checking.

Even x_socket() error checking can be safely skipped in a correct
program, if it can be guaranteed that a stub can always be returned
safely (viz., without dynamic memory allocation).  If doing this
without dynamic memory allocation is not expedient, I don't think that
croaking inside x_socket() would be a deal that's too bad: very few
programs can do anything meaningful upon encountering malloc()
failure.  If needed, here's a compromise: let the x_socket caller pass
the already-allocated space as an argument optionally.  The typical
caller will give a NULL in that place and have the x_socket() perform
exit(1) if memory allocation fails; the unusual caller that knows what
to do if malloc() fails can call it by itself and pass the result to
x_socket().  How is that?

> I agree here that a socket specific error
> checking is useful in certain situations. it sometimes is also helpful
> when programmers forgot to do error checking somewhere in the program.

Which, in my book, justifies it (unless there's a reason not to do it,
which I don't see -- other than the space to record the error, which,
we agree, is not a problem).

> So this is an advantage, and the disadvantage is that addition stuff such
> as x_socketerr(LAST_ERROR) still needs to be defined,

Yep, or perhaps a different mechanism for errors that are not related
to a specific stream.  I don't see cases other than x_select() that
need the special treatment (and x_select is easy to deal with: return
-1 or something like that and leave the system errno intact).

> and such kind of error checking will encourage people to delay or
> omit some error checking, which sometimes is not good, as I
> mentioned in the above example.

That's very close to the ``seat belts encourage reckless driving''
argument.  I'm not sure I buy this point.

-- 
Stanislav Shalunov              http://www.internet2.edu/~shalunov/

"The power of accurate observation is commonly called cynicism by
those who have not got it."                     -- G. B. Shaw