|
Home > Archive > Unix Programming > July 2005 > get{peer,sock}name on AF_UNIX sockets
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
get{peer,sock}name on AF_UNIX sockets
|
|
| Michael B Allen 2005-07-24, 5:52 pm |
| Is there a way to get the name of a unix socket like you
can using inet_ntoa with a regular socket? I thought perhaps
get{peer,sock}name might be suitable to then reference ((struct
sockaddr_un *)&addr)->sun_path but this information appears to be absent
or garbage (accept(2) returns len 2 and getsockname(2) claim the size
if the address is 18 bytes:
00000: 01 00 5d 00 8c 75 5e 00 58 fb e0 00 f0 2c e6 bf 98 26 \
|..]..u^.X....,...& |
but the offsetof sun_path is only 2).
Am I doing something wrong here?
Thanks,
Mike
| |
| Michael B Allen 2005-07-24, 8:50 pm |
| On Sun, 24 Jul 2005 16:07:16 -0400, Michael B Allen wrote:
> Is there a way to get the name of a unix socket like you
> can using inet_ntoa with a regular socket? I thought perhaps
> get{peer,sock}name might be suitable to then reference ((struct
> sockaddr_un *)&addr)->sun_path but this information appears to be absent
> or garbage (accept(2) returns len 2 and getsockname(2) claim the size
> if the address is 18 bytes:
>
> 00000: 01 00 5d 00 8c 75 5e 00 58 fb e0 00 f0 2c e6 bf 98 26 \
> |..]..u^.X....,...& |
>
> but the offsetof sun_path is only 2).
>
> Am I doing something wrong here?
At second glance getsockname(2) DOES work with AF_UNIX sockets (my length
parameter was being clobbered by accept(2)).
But accept(2) and getpeername(2) return a length of 2 which is just the
sa_family member. I guess the reasoning is that there is no such thing
as a remote address for a UNIX socket? Personally I would prefer to see
accept(2) and getpeername(2) return the sun_path also.
Oh, well,
Mike
| |
| William Ahern 2005-07-25, 3:04 am |
| Michael B Allen <mba2000@ioplex.com> wrote:
> On Sun, 24 Jul 2005 16:07:16 -0400, Michael B Allen wrote:
>
> At second glance getsockname(2) DOES work with AF_UNIX sockets (my length
> parameter was being clobbered by accept(2)).
>
> But accept(2) and getpeername(2) return a length of 2 which is just the
> sa_family member. I guess the reasoning is that there is no such thing
> as a remote address for a UNIX socket? Personally I would prefer to see
> accept(2) and getpeername(2) return the sun_path also.
Technically the peer name might have been deleted or renamed. AFAICT,
getting the sun_path from getsockname(2) is a nice convenience, but in
itself doesn't really fit with traditional Unix conventions. You can't get
the path of a file descriptor returned from opening a regular file, for
instance.
Plan9 said to hell with it, and got around all the inherent problems by
judging the passed path as "good enough". Linux took the hard road and tries
to track inode<->path mappings in the kernel--exposed through
/proc--but I think Plan9 made the better call.
| |
| Michael B Allen 2005-07-25, 3:04 am |
| On Sun, 24 Jul 2005 21:23:54 -0400, Michael B Allen wrote:
> But accept(2) and getpeername(2) return a length of 2 which is just the
> sa_family member. I guess the reasoning is that there is no such thing
> as a remote address for a UNIX socket? Personally I would prefer to see
For the sake of completeness I have another correction.
If the AF_UNIX socket is a client oriented socket getpeername(2) does
fill in sun_path and getsockname(2) does not (whereas the reverse is
true of a server oriented socket).
But because the POSIX docs do not really specify what the proper behavior
is I suspect results on platforms other than Linux may not be consistent
with my observations.
Mike
| |
| Frank Cusack 2005-07-25, 6:07 pm |
| On Mon, 25 Jul 2005 02:17:13 -0400 Michael B Allen <mba2000@ioplex.com> wrote:
> If the AF_UNIX socket is a client oriented socket getpeername(2) does
> fill in sun_path and getsockname(2) does not (whereas the reverse is
> true of a server oriented socket).
What is a client oriented socket, and what is a server oriented socket?
-frank
| |
| Michael B Allen 2005-07-26, 7:59 am |
| On Mon, 25 Jul 2005 10:49:56 -0700, Frank Cusack wrote:
> On Mon, 25 Jul 2005 02:17:13 -0400 Michael B Allen <mba2000@ioplex.com> wrote:
>
> What is a client oriented socket, and what is a server oriented socket?
By "client oriented socket" I mean a socket created by calling
socket(2)+connect(2). This is the "client" because it is the end that
initiates the connection.
By "server oriented socket" I mean a socket created using accept(2). This
is the "server" because it is passive.
And a socket created using socket(2)+bind(2)+listen(2) does not have an
orientation because no application layer data is written to or read from
it so it is what I would call a "server socket".
Mike
|
|
|
|
|