LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

getpeername.2: Clarify semantics of getpeername() for datagram sockets 

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674034

Reported-by: Kai Kunschke <kai@kunfoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2013-02-12 21:26:38 +01:00
parent c2da6a279c
commit 0c56d91757
1 changed files with 29 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
man2/getpeername.2
View File

@ -37,7 +37,7 @@
.\" Modified 17 Jul 2002, Michael Kerrisk <mtk.manpages@gmail.com>
.\" Added 'socket' to NAME, so that "man -k socket" will show this page.
.\"
.TH GETPEERNAME 2 2008-12-03 "Linux" "Linux Programmer's Manual"
.TH GETPEERNAME 2 2013-02-12 "Linux" "Linux Programmer's Manual"
.SH NAME
getpeername \- get name of connected peer socket
.SH SYNOPSIS
@ -111,6 +111,34 @@ Some POSIX confusion resulted in the present
also used by glibc.
See also
.BR accept (2).
For stream sockets, once a
.BR connect (2)
has been performed, either socket can call
.BR getpeername ()
to obtain the address of the peer socket.
On the other hand, datagram sockets are connectionless.
Calling
.BR connect (2)
on a datagram socket merely sets the peer address for outgoing
datagrams sent with
.BR write (2)
or
.BR recv (2).
The caller of
.BR connect (2)
can use
.BR getpeername ()
to obtain the peer address that it earlier set for the socket.
However, the peer socket is unaware of this information, and calling
.BR getpeername ()
on the peer socket will return no useful information (unless a
.BR connect (2)
call was also executed on the peer).
Note also that the receiver of a datagram can obtain
the address of the sender when using
.BR recvfrom (2).
.SH "SEE ALSO"
.BR accept (2),
.BR bind (2),