Re: OT: getting the protocol family of a file descriptor

Am Donnerstag, 31. Januar 2008 16:31:32 schrieben Sie:
"Heiko Wundram (Beenic)" <wundram@xxxxxxxxxx> writes:
I'm currently in the need to get the protocol family that was used to
create a socket (and passed via a unix domain socket to another
program), and I've not really come up with a proper scheme other than
to use getsockname and retrieve sa_family from the resulting socket
(which currently matches the socket domain and historically has, but
why take the chances ;-)).

This is the correct way to do it, I don't understand why you think it
might not work in the future.

Is there any other "better" way to get at the domain (protocol family)
of a socket?

Why should there be a better way?

Just like there is getsockopt(fd,SOL_SOCKET,SO_TYPE), I'd (somehow) assume
that there's a getsockopt(fd,SOL_SOCKET,SO_DOMAIN/SO_FAMILY).

I can understand that the actual protocol used to create a socket is
irrelevant in most of the applications which get sockets from "outside" (as
long as the type they want matches the type of the passed socket), and I've
not found any (general [!], of course there's specific ways depending on the
PF) way to get at that yet from a file-descriptor, but I can't understand why
this also applies to the domain, as for example in case you're trying to
format the address a socket is bound/connected to in a user-readable manner,
you will have different code depending on the actual address type.

Currently, you're basically required to do a getsockname to a struct
sockaddr_storage and typecast that to the actual socket addres type based on
the ss_family member (to be able to pass it to one of the *_ntop-functions,
for example), but generally, I don't find this too beautiful. But, maybe,
that's just my (horribly broken) taste. ;-)

--
Heiko Wundram
Product & Application Development
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Updated fine-grain locking patch for UNIX domain sockets
    ... Attached, and at the below URL, find an updated copy of the UNIX domain socket fine-grained locking patch. ... Since the last revision, I've updated the patch to close several race conditions historically present in UNIX domain sockets, as well as move to an rwlock for the global lock. ... int); ...
    (freebsd-performance)
  • Re: getting client ip in sock-client on server
    ... getsockname using PInvoke mechanism. ... will give you the remote address and getsockname will give you the local ... address for the connection. ... socket handle and pass it into these API as parameters. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Mapping local ports to connected sockets
    ... which socket is making the connetion ... I tried enumerating all sockets and do getsockname on them, ... so even though connecthas returned, getsockname returns error. ... connection has been accepted by the other side). ...
    (microsoft.public.win32.programmer.networks)
  • Re: kernel assigned port (solved :-)
    ... kokje@usc.edu (Tejas Kokje) wrote: ... getsockname() does the trick for me. ... > argument which is socket address structure. ...
    (comp.unix.programmer)
  • Re: UNIX domain sockets MFCs
    ... new reports of UNIX domain socket problems in the last couple of days, it sounds like the MFC of the last batch of fixes and cleanups has not lead to problems. ... I think we have a leak in the way some edge case is handled with regard to UNIX domain socket shutdown. ... processes in a soclose state, ...
    (freebsd-stable)