0

I want to make a peer-to-peer program in Python, but I keep running into the same issue of how to get them to communicate. I always run into the same answers.

  1. Use a central server
  2. UDP hole punching, or
  3. use UPnP to tell the router to open a port.

The second and third I haven't gotten to work despite hours of trying. Multiple libraries simply didn't work, and for the second I have no rendezvous server. For the first, I have tried to use the freenode IRC server as the central server, but it is quite unreliable and complicated, and just doesn't feel like a good solution.

Is there any other way? Or solutions to the above problems?

Daffy
  • 841
  • 9
  • 23
  • The only other way is to tell the user to manually go open a port, which usually isn't sufficient as the main solution (but notice that many BitTorrent clients do offer it as a fallback for users with, e.g., weird setups). – abarnert Jul 08 '18 at 05:56
  • @abarnert As I said in the title, but neglected to mention again in the body, is that port forwarding isn't really an option here. I'm looking for a general solution where you could ideally download the program onto any generic computer and have it work without special settings. – Daffy Jul 08 '18 at 05:58
  • Also, are you building just a one-to-one P2P system, or a multi-user mesh? With a mesh, most of the time, the peers can introduce each other without needing the server to get involved. You need some kind of introducer to bootstrap people behind NATs into the mesh in the first place, and to fall back on when nothing else will do, but if the introducer is only serving 5% of the introductions instead of 100%, it doesn't have to be nearly as performant and reliable. – abarnert Jul 08 '18 at 05:59
  • @abarnert You can assume the IP addresses of all clients is known and a non-issue. The issue is getting a connection in the first place. – Daffy Jul 08 '18 at 06:01
  • 1
    What you're asking for in the title is impossible. There is no way to make a UDP connection between two clients without port forwarding or hole punching. The three options you gave are (1) not P2P, (2) hole punching, and (3) automated port forwarding. The only option you left out is (4) manual port forwarding. There is nothing else. There might be variations (e.g., a distributed network of servers—or even making peers who aren't behind NAT act as servers—instead of a central server), but they're all variations on these. – abarnert Jul 08 '18 at 06:01
  • If the IP addresses of all clients is known, then hole punching is the answer. If you haven't got it working, I don't know what to tell you. It's certainly doable. Thousands of programs do it every day for millions of people. Presumably there's some flaw in the way you're trying to do it, but without any idea of how you're doing it, nobody can fix that flaw for you. – abarnert Jul 08 '18 at 06:02
  • @abarnert the main issue with hole punching I have is I have no rendezvous server to even attempt it with. Is there a public one? – Daffy Jul 08 '18 at 06:05
  • You need a rendezvous server for two cases: (1) two peers want to communicate but don't know each others' IPs, or (2) two peers don't both actually know they want to communicate (and that information can't be passed to them through the mesh or otherwise). Without any information about what you're trying to build but "a peer-to-peer program", I really have no idea what you need, but it doesn't sound like you need either. – abarnert Jul 08 '18 at 06:13
  • 1
    *The second and third I haven't gotten to work despite hours of trying. Multiple libraries simply didn't work* - well, maybe you should post questions about these issues then instead of asking for a miracle solution. – the8472 Jul 08 '18 at 22:07
  • @the8472 +1, though I was hoping there was some method that nobody's told me about yet. Turns out wishing doesn't make it true. – Daffy Jul 09 '18 at 05:35

0 Answers0