Tonight I looked into newly implemented SPX protocol (af_spx.c, as of
2.1.99-pre3).
After that process it became unclear to me :-), what should be the correct
interface with
non-blocking connect() call.
Currently, spx_connect() simply initiates a handshake by sending CONN-REQUEST,
and return EWOULDBLOCK if O_NONBLOCK flag is set on this socket.
Later, on repeating call to connect(), it will initiate handshake once more
(i.e.
CONN-REQUEST packet will be resend and socket state will be set to CONNECTING
once more).
And so on.
I expected more natural behavior: after the very first connect() call, even
after EWOULDBLOCK,
we should keep tracking socket state inside kernel using already sent
CONN-REQUEST packet
(retransmitting it only on timeout). Further calls to connect() should check
the tracked state
and return immediatly if connection has been established (rather then initiate
one more CONN-
REQUEST).
Is it correct, or I'm wrong?
By the way, what should be the errno value for non-blocking connect?
Linux SPX, NETROM, and some others return EWOULDBLOCK while
Linux TCP/IP returns EINPROGRESS on the first connect() and
EALREADY for all subsequent connect() calls until connection will
be establised. For established connection, it returns EISCONN.
Is this behaviour documented and/or conforms to standard?
I'm going slightly fix SPX stack (my purpose is to get a stable btrieve
connection with Netware server),
so I ask somebody with network interface knowledge to give me more information
on how these things
should look like.
Yet another problem with af_spx.c: it seems it will not retransmit connection
request if server does
not reply with ACK. I wonder, does somebody get positive results with the
current implementation?
Please keep inform me if you found/fixed a bug within it. I'll try to
summarize this information and
work on more stable/usable SPX for Linux.
Thanks!
Yuri Pudgorodsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu