Transport protocols and bulk file transfer

[stanislav shalunov <>]

Yunhong Gu 
<>
 writes:

> X_SOCKET s = x_socket(AF_INET, SOCK_STREAM, 0);
> if (INVALID_SOCK == s)
>    printf("error d%\n", x_sockerror(???)");
> 
> what socket id can you use here as a parameter of the above x_sockerror(),
> since you don't even have a valid socket id yet.

For purposes such as these, a last error function would, indeed, be
preferable.  (The unix approach is to put that kind of stuff in errno,
but an errno() would be cleaner, while the efficiency advantage in
error handling is usually unimportant.)

However, something like the following could be correct for appropriate
API definition:

        X_SOCKET s;
        X_ERROR_T errcode;
        s = x_socket(...);
        x_connect(s, ...);
        x_sendfile(s, ...);
        x_close(s);
        errcode = x_sockerror(s);
        if (errcode) {
                x_whine_about(errcode);
                exit(1);
        }

Read errors would still need to be propagated up the call chain, but
write errors could be handled in more compact, easier to understand
code.  More importantly, code easier to write: if you don't care about
this, you could check for errors each time as you are mostly supposed
to do in C.  If you forget to do so because the call ``should''
succeed (many people do that with things like close(2) or socket(2)),
the error is still recorded and might be reported later after a
less-obvious call.  This, of course, is less likely to happen with
x_close() than with x_socket(), so the exception mechanism is very
imperfect, but it seems better than nothing -- and almost free.

> another example is x_select(). The error of x_select() can be meaningless
> for any particular sockets, i.e.:
> if (-1 == x_select(...))
>    printf("error d%\n", x_sockerror(???)");

Agreed.

> While you can use a special number like -1 to check such error
> (e.g., x_sockerror(-1)), but this does not looks good :) and this
> still need to be checked right after a socket function is called.

I'm not sure what should be the way to handle the last error case, but
x_sockerror(X_LAST_ERROR) might not be the worst thing in the world.
(Note that X_SOCKET is likely to be a structure of some kind, so -1
wouldn't work too well -- at least not without really dirty tricks.)

> I was not concerning about the additional storage, I just thought if a
> parameter is not very useful, adding it may bring possible trouble.

Does the example above show why it could be made useful?

> If the programmer does not check the error right after a function call,
> they, most likely, will not check it later :)

I'm not about to dig into UDT code to look for missed error checks,
but most people (and even most computers, for that matter, but that's
off-topic), once in a while, make mistakes.  Making the consequences
of mistakes less catastrophic without paying much for it seems like a
reasonable thing.

> error code is ok. An integer code is convinient for programming. I
> am afraid that for a user level implementation, error codes in
> errno.h may not be sufficient.

I was thinking about perhaps making the error type a typedef to help
compilers.  Not sure if enum is a good choice for this.  That kind of
thing.

> In addition, a helper function can be used to print text error
> information, just like perror.

So, some kind of char *x_strerror(X_ERROR_T errcode)...

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

This message is designed to be viewed upside down.