On 2021-02-22,
[email protected] <
[email protected]> wrote:
On Sat, 20 Feb 2021 17:59:47 -0500
Barry Margolin <[email protected]> wrote:
No it doesn't, it just returns the socket FD, and you then call >>getpeername(). You may be thinking of recvfrom(). This is normally used >>with UDP sockets, but I suppose it will also work with TCP.
Turns out it does and thats what I used in the end.
Right. getpeername can be seen as useful for situations where you have
one place in the program which is doing the recv (like some low level
I/O routine in a I/O library that is used by everything else). You
don't want every recv call on a stream to be getting the address, which
doesn't change over the life of a stream.
You might want to know the peer's address right away without waiting for
it to send data first, and for some reason you didn't get that from
accept (because that happened in another module or even another
separate program, which handed you a file descriptor).
Knowing the peer's address before performing input can be useful. Say
that some malicious IP address range is generating "honeypot" behaviors:
peers from that range hold the connection open, but don't send any data.
The user of your program would like to put in an IP-based rule block
that address range but, oops, your program doesn't determine the remote
IP until it reads data.
--
TXR Programming Language:
http://nongnu.org/txr
Cygna: Cygwin Native Application Library:
http://kylheku.com/cygnal
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)