Sending files over IRC reddit / irc ---------------------------------------------------------------------- JSV007 · 2022-03-09 04:53 Hi, Today I finally got my IRC server setup, I can chat with my friends and it works well for basic communications ! I am using hexchat and ergo as my IRC server client. When trying to send files to my friend, he will see a notification asking him if he wants to download it , accepts, but nothing will happen and the file will not upload. Any ideas about this ? I have tried asking about this on the ergo IRC channel and didn't really get a concrete response. ---------------------------------------------------------------------- ferrybig · 2022-03-09 08:20 Files are transferred via the DCC specification. The sender opens an local port and tells the remote side its port. Once the other party accepts the request, it connects back to the IP and port of the sender and downloads the file. This allows fr a peer t peer transfer of the files without going via the IRC server. Note that this is not compatible with NAT devices or firewalls on the path. When you use NAT, you need to forwards the port range of DCC. If you use firewalls on the path, you need to allow the port range of DCC. If both clients are behind the same NAT device, the nat device also needs to support NAT loopback ---------------------------------------------------------------------- SqualorTrawler · 2022-03-09 17:23 I feel sometimes like the guys who created FTP and the guys who created DCC were drinking buddies. ---------------------------------------------------------------------- ProgVal · 2022-03-09 18:30 To be fair, NAT was almost non-existent when both were designed ---------------------------------------------------------------------- ferrybig · 2022-03-09 19:19 FTP and DCC were invented before we invented NAT, every computer had its own IP address and the only firewall was on the PC's themselves. DCC stands for Direct Client to Client, which allowed clients to connect to each other without going via the server. Great (at the time) for privacy sensitive chats and sending files. *Note that any kind of encryption is not part of this because it wasn't a concern back at the time.* With the IPv4 shortage, NAT was invented, breaking many protocols of the time, it even affected IRC as servers were no longer able to send an ident request to the people joining. Now we are even deeper in IPv4 shortage, and we are going to IPv4 without any user access to port forwarding or *even symmetric NAT for some ISP's.* We solved this by inventing IPv6, designed to restore peer to peer communication that we no longer have with NATTED IPv4 These days, to account for many different ways of devices can and cannot request, we use [Interactive Connectivity Establishment](https://datatracker.ietf.org/doc/html/rfc5245#page-28) for things like online meetings en discord calls. ---------------------------------------------------------------------- DingDingWinner1 · 2022-03-09 20:38 Good info! Just learned about hairpin NAT/NAT Reflection/NAT Loopback for work. Not all routers support that option, I would add. ---------------------------------------------------------------------- zedSuperior · 2022-04-04 00:52 You could maybe upload the files on an online drive, share the drive file and send the link in chat. ---------------------------------------------------------------------- istarian · 2022-07-07 22:08 Is there a good source to read up on that latter bit? Why would the relative shortage of IPv4 addresses affect access to port forwarding or symmetric NAT? I assume you could perform an end-run around most of the problem with a VPN setup? Meaning that you connect to a network with everybody else and then everyone chatting and the server would be local to that network. ——— I sure wish people would stop and ask how things could be improved without stacking complexity on top of complexity. ---------------------------------------------------------------------- ferrybig · 2022-07-09 19:50 >Why would the relative shortage of IPv4 addresses affect access to port forwarding or symmetric NAT? We are at the point where ISP's have more customers than he number of IPv4 addresses. Instead of denying new people access to IPv4, many instead deploy a solution known as carrier grade nat. This places multiple people behind one large NAT gateway. One major drawback of this is that people effectively only have outgoing IPv4, an no longer have incoming IPv4. >I assume you could perform an end-run around most of the problem with a VPN setup? Meaning that you connect to a network with everybody else and then everyone chatting and the server would be local to that network. While it could work, we are now back at the old issue. We are now limited by the bandwidth of the server again. This won't scale up if 100 people try to transfer files at the same time. Applications like Discord have their servers transfer the files, instead of doing it peer to peer, but because of the server bandwidth usage, they limit files to 15MB. Platforms like skype did files peer to peer, so they did not come with an file limit. > Is there a good source to read up on that latter bit? This comes from the VOIP world. In the VOIP world, companies would have many IP phones all throughout the building. Setting up a VOIP connection is a peer to peer connection. Setting up port forwarding for like 100-200 phones is just unfeasible to manage. Instead, it uses ICE A voip connection can be seen as the following: A: Makes UDP socket A -> stun server: What is my IP+port Stun server -> A: Your ip is xxx.xxx.xxx.xxx:xxxx, your IPv6 is \[zzzz:zzzz:zzzz::zzzz\]:zzzz (via another "control" connection) A --> server --> B: Hello B, I want to connect a voice session with audio CODEX A, B, C. My LAN IP is IPv4:yyy.yyy.yyy.yyy:yyyy, IPv6:\[zzzz:zzzz:zzz::zzzz\]:zzzz, my WAN ip is IPv4:xxx.xxx.xxx.xxx:xxxx, B: Makes UDP socket B-> stun server: What is my ip stun server -> B: Your IP is aaa.aaa.aaa.aaa (no ipv6 on this peer) (via another "control" connection) B --> server --> A: Here if my answer: Use codex A, My lan IP is IPv4:bbb.bbb.bbb.bbb:bbbb, my WAN IP is IPv4:aaa.aaa.aaa.aaa:aaaa (Both parties now send connectivity checks to the IP's reported by the other side.) Connectivity checks are done in priority order. Both sides validate every pair. Once the controlling side has seen that a pair has successful connectivity checks in both directions, it promotes that pair and setups the application specific connection. >I sure wish people would stop and ask how things could be improved without stacking complexity on top of complexity. **One major advantage of this is,** that it basically makes it look to the firewall as an outgoing connection from both sides. This means no port forwarding is required. *From the users perspective, this way of connection makes it way simpler, although the code in the application becomes more complicated*. IP cams using this way of connecting no longer needs port forwarding, *which makes them plug and use for the end user.* Modern applications go one step further, they use Trickle ICE instead of ICE. An empty offer/answer is send, and then the candidate collection progress starts, where candidates are collected, and the local UDP socket is opened. See also [https://webrtchacks.com/an-intro-to-webrtcs-natfirewall- problem/](https://webrtchacks.com/an-intro-to-webrtcs-natfirewall- problem/) ---------------------------------------------------------------------- istarian · 2022-07-09 21:31 Thanks! The linked page definitely does a better job of explaining the issue you were talking about, especially with pictures. I’m not sure why using a VPN has to create a bandwidth problem though. Even a “normal” peer to peer connection has to traverse the network. Are we assuming a *naive* server setup where all the clients connect directly to the server over the same network interface? ——— It certainly seems like moving all traffic to IPv6 and then tunneling IPv4 as needed to form virtual IPv4 networks would make the most sense. Although it would probably incur some cost on the remote end in terms of some kind of gateway… In theory, endpoints could be IPv4 if most other things talked via IPv6 or vice versa. ---------------------------------------------------------------------- ferrybig · 2022-07-10 21:39 >I’m not sure why using a VPN has to create a bandwidth problem though. Even a “normal” peer to peer connection has to traverse the network. > >Are we assuming a naive server setup where all the clients connect directly to the server over the same network interface? This is on the server side. Normal IRC traffic is maybe like 1-5kbps max per connected client on server. Tcp buffer are tuned to be small like 10k in size per client. Sending files or managing a VPN from the server itself would be way more data and more buffer space per client, as people would otherwise complain of slow speeds. *If you want to run a peer to peer vpn*, you are back to the original issue of connecting between people. >It certainly seems like moving all traffic to IPv6 and then tunneling IPv4 as needed to form virtual IPv4 networks would make the most sense. Although it would probably incur some cost on the remote end in terms of some kind of gateway… In theory, endpoints could be IPv4 if most other things talked via IPv6 or vice versa. If you already have a peer-to-peer connection between 2 user setup, just skip the extra IP layer on top and directly send UDP/TCP or even your application stuff directly ---------------------------------------------------------------------- garfolino · 2023-11-04 00:15 How come theres no more DCC protocols? I cant find a way to transfer files from me to a friend without using some sort of cloud service.