YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> Because it is protocol (such as ipv4 or ipv6) dependent.
Hmmm... I had thought of RxRPC being very transport dependent, being rather
tied to UDPv4, though probably simply extensible to UDPv6. However, as long
as the transport-layer header is removed on received packets before the main
part of the code sees them, there shouldn't be any problem supporting non-UDP
protocols, apart from, possibly, network error (ICMP) handling.
Some of the AFS operations, however, only deal in IPv4 addresses. I believe
there is work afoot to deal with this, but I as far as I know it hasn't been
dealt with yet.
Currently RxRPC is *only* available over UDPv4 in OpenAFS as far as I know.
> You cannot use different sturcture for one address family.
> You could use union, maybe.
I am using a union:
struct sockaddr_rxrpc {
sa_family_t srx_family;
u16 srx_service;
u16 transport_type;
u16 transport_len;
union {
sa_family_t family;
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
} transport;
};
I can add the alignment restrictor to the union though.
> Another option would be to introduce new transport protocol such as
> dccp or sctp, no?
It's not my choice. My code must interoperate with the other RxRPC/AFS
implementations that are already out there and have been around for many
years.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
