Mihir Luthra <luthramihir...@gmail.com> wrote in <CAEa=dYCv=b7jxw4ajc+gbnac7z_seiuhwypz5vxjundkzvv...@mail.gmail.com>:
lu> > lu> > lu> > I think you should learn TI-RPC API first. The nettype specifies a lu> > class of transport protocol, not address family. lu> > lu> > Thanks, I did some more research on TI-RPC today. lu> In `statd.c` what I see is in `create_service()`/`complete_service()`, lu> transport info is being fetched through getnetconfig(), which makes it lu> listen on all transports. I guess its clean in `statd.c` but same can also lu> be done in `procs.c`/`file.c`. Maybe trying all transports until it finds lu> one which is connectionless? Apologies if I got something wrong, new to lu> this topic. clnt_create() checks /etc/netconfig and tries all of the transport protocols with the specified class which are listed there, and then chooses the first usable one. So if IPv6 is available, "udp6" will be used because it is before "udp". statd.c handles the bind addresses on the server (service) side while file.c and procs.c handle the client calls. They are different. lu> Also, while looking at the code, I think it always assumes ipv4 is always lu> present. Like `127.0.0.1` is added to host list always. On ipv6 only lu> machine this may fail. Yes. We should fix this kind of hardcoded loopback addresses and make userland utilities transport-independent wherever possible. It can be replaced with getaddrinfo() with AF_UNSPEC for all available address families. -- Hiroki
pgphQfOnGgGXL.pgp
Description: PGP signature
