Closed moshekaplan closed 5 years ago
I'm not sure I understand the motivation for this change.
sending a file via DCC over the Internet requires sending a public IP address, not the internal private IP
Can you describe the scenario where the address returned by gethostbyname(gethostname())
is not the desired interface?
Would it be better instead to bind to the first address returned by getaddrinfo(None)
, such as with this code?
The port needs to be configurable
Are you suggesting that a user would route a particular port or series of ports through the firewall and then would use one of those pre-allocated ports in the DCC connection? ...rather than what they could do today which is bind to the port and then authorize the ephemeral port to be routed through the firewall?
I'm generally in favor of this change except for two things.
(None, 0)
. The code should probably pass this parameter to socket.getaddrinfo
to determine the address family to which to bind.So if you can address (1), then I'll accept the change.
Can you describe the scenario where the address returned by gethostbyname(gethostname()) is not the desired interface?
An example is a machine with multiple network interfaces. They may want to expose the IRC server to one network and not another.
Would it be better instead to bind to the first address returned by
getaddrinfo(None)
, such as with this code?
I don't think so. getaddrinfo(None, 0)
appears to default to localhost (at least on my Windows system), which wouldn't be very useful for most users.
Are you suggesting that a user would route a particular port or series of ports through the firewall and then would use one of those pre-allocated ports in the DCC connection? ...rather than what they could do today which is bind to the port and then authorize the ephemeral port to be routed through the firewall?
Yes. I was under the impression that's how most IRC clients (mIRC, Hexchat, etc.) implement DCC sending. There might be security concerns with having a massive range of ports open all the time. I'm personally not aware of how an application would 'inform' a firewall to dynamically allow an incoming TCP connection. If you have any reading material on the subject, I'd like to learn more.
To make sure we're on the same page, here's my understanding of how DCC sends operate (at least on mIRC, which is one of the more popular windows IRC clients)
Ideally, this package would also support long-running instances, so it would require timing-out DCC sends if the client doesn't connect and re-adding the port to the pool when the transfer is complete.
I'm personally not aware of how an application would 'inform' a firewall to dynamically allow an incoming TCP connection. If you have any reading material on the subject, I'd like to learn more.
There are basically two protocols, Nat-PMP and UPnP. Most routers support one or the other, some out of the box and others after enabling the feature. So you're right, there's not a simple, reliable way to dynamically allocate ports to a given host... although certainly some systems like Xbox have engineered a solution that works in most environments. I'm not aware of anything in the Python ecosystem that abstracts this need. I have taken over maintenance of the nat-pmp library for Python, so can offer that as a possible solution.
But I agree - that's outside the scope of this effort, which is simply to give IRC the ability to listen on a pre-determined port.
getaddrinfo(None, 0)
appears to default to localhost
I see the same on macOS. I continue to struggle with what I typically want - listen on all interfaces, IPv4 and IPv6.
Okay, so just to re-iterate, the only change I'm seeking still is to combine the host/port into one addr parameter. I'll see if I can push that over the line.
The library currently doesn't allow controlling which IP address or port are used for DCC.