Arnaldo,
can you please look at these patches with priority and consider these or a
variation
for mainline - it is in response to the comment made by Remi about handling
non-blocking
connect by looking at socket error codes.
Patches #1/#2 are related, but not the main point. They fix the error reporting
when e.g.
the server has no DCCP loaded and ICMP "Protocol unavailable" is
returned.
This was so far not interpretated.
Patch #3 is the one for I would be glad for feedback. This fixes the problem
Remi reported,
by interpreting the Reset code of the Reset packet. In this way, it is
now possible
to separate clean termination (sk_err == 0) from genuine errors
(sk_err != 0). Now,
the choices were:
1) Mimic tcp_reset() by mapping "No Connection"/"Connection refused"
to ECONNREFUSED
and map everything else to ECONNRESET.
The problem that I found with this is that it throws away the
variety of Reset codes
defined by DCCP.
2) Map "No Connection"/"Connection refused" to ECONNREFUSED and
everything else using
a mapping scheme (e.g. bit-shift reset code + adding a constant).
But this may lead
to strange error codes when the scheme overlaps with existing error
codes.
3) Map as far as possible into error numbers. This has been done in
the present patch,
using a table (which could be easily changed). The difficulty that
I found here is
that the range of errnos is limited, so it is a kind of best-guess.
For instance,
"Agression penalty" is mapped into EDQUOT, which looks a bit
strange when directly
putting this into strerror(). But the advantage is that the API can
catch and reinterpret
this.
It is all very elementary, but has been found to work. I hope that there are
ideas and suggestions as
to how to extend this (for instance the Data 1 ... 3 fields are not yet
interpreted), but in light of
Remi's VLC patch it would be good to have at least a subset of this available
in mainline - experimental
things can then remain in the test tree.
Best regards
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
