[Open thread]Multiplayer discussion


#21

https://os.mbed.com/docs/v5.9/reference/circularbuffer.html


#22

Latest developments

I am working on a cross-platform client that will connect as follows:

Pokitto->USBSerial->Native desktop client software->UDP->Pokitto Game Server->UDP->Native desktop client 2->USBSerial->Pokitto2

… and it’s extremely complicated. I never realized that over the internet multiplayer programming is so incredibly hard.

So far I have a TCP/UDP server running on a VPS and I can join and send messages via TCP and UDP but I can’t seem to figure out port redirection and especially UPnP

Getting everything to work on localhost is a piece of cake but I am getting seriously stumped by how to get the messages from the game server back through the router and NAT

If you have experience in these matters, any help would be appreciated!

Also, I have considered the following architectures:

  1. Native clients with TCP & UDP
  2. Python clients with TCP & UDP
  3. Python clients with WebSockets
  4. Native clients with WebRTC

I chose #1 because with PokittoPOP programmer I am already making native software with Xojo, Xojo has extensive support for Com serial and TCP/UDP. UDP is also by far the most suitable protocol for interactive games.

first punch through achieved

2 win clients connecting to a win server using a 3rd party ubuntu server for NAT punch trough, success


#23

Am I the only one interested / with experience of this topic?

I’ve spent several days trying NAT traversal and its bloody awful difficult

I get stumped at the P2P connection and I think I will have to abandon UDP P2P. It is just too hard for me.


#24

I’ve never really looked into multiplayer to tell the truth. Not that I haven’t been interested, just it sounds a bit complicated.


#25

It’s very difficult to debug. You have the round trip to the public server and back, passing through 2 routers and firewalls on local computers.

Then you have Wireshark running on the clients and iptraf on the server and several SSH connections and you try to filter out the TCP/UDP data that is happening in your program.

At the moment i am at the point where clients have the correct host & port info on each other and both of them try to connect with the other, but my Huawei router is blocking it and I have no clue how to debug why it is blocking


#26

In all honesty I don’t have much experience with internet connectivity.

I understand UDP and I have a vague idea of how TCP works and how the different layers of a packet work, but overall I don’t have much experience with it.

(From what I’ve read, I find that the technologies that drive the internet seem to be horribly overcomplicated.)

My Python experience is limited too.


I’m trying to take a break from programming anyway.
I’ve managed to stop myself doing any programming for several days now,
though I haven’t been able to avoid contributing to forums.

I suspect many other people have been taking a break as well.


#27

So right now you have a public Pokitto Server that allow two client to “handshake” port and ip to later enable a UDP connection.
Is this done via TCP or by UDP ?
Can you using the same socket to establish the peer to peer connection, keeping the connection alive?

If the P2P way is blocked you could go back to a routing all the traffic using the public server. I know it will use some precious bandwidth and will add more latency, but could be quick and dirty solution for now.


#28

Yep. I have an Enet (open-source game networking protocol, TCP for handshakes, reliabile UDP packets for real time comms) server running on a cloud. Clients exchange host addresses via the handshake server (TCP) and then try to connect to each other. The UPnP does not work, my conical NAT does not open the tunnel and I simply do not know why. The router does not give any options for debugging. All I can see is the packets do not go through.

I am going to do exactly what you said, ie. make a public relay server. That will allow me to get it working while I try to find ways to fix the issue later.

As a side note, it appears even large software houses have trouble making NAT tunneling and their client software employs lots if different alternative techniques to make it work.

(Edit: also considering WebSockets but afaik different sources say wss latency is 10x higher than plain TCP sockets… @FManga?)


#29

And someone make fortunes on this.


#30

I’d find that surprising. WS have a little bit of overhead at first (initial handshake so the browser can punch through proxies/firewalls and knows WS are supported by the final server), but after that it should be just as fast as regular TCP. Maybe those reports were measuring the total time and not actual latency? It’s used for streaming realtime sound/video, so a 10x latency would be unacceptable.
The only scenario where I’d expect that sort of latency is if there was something slow in the middle (a proxy?) or if a library was used and it fell back to long-polling over HTTP for some reason.

That said, I’ve never done actual benchmarks comparing WS to raw sockets. I’ve made multipayer games that use one or the other (or HTTP polling), but minimized the data transfered to a point where speed wasn’t an issue. Of course, that’s not always possible. It’s expected that an FPS or fighting game might have to resort to UDP but an MMO or turn-based game would be fine with TCP/websockets.


#31

I may have found the issue.

I didn’t realize the clients were binding themselves to my ncap loopback adapter.


#32

heisenberg principle hit again

image


#33

It works.

Watch this space.


#34

That’s exciting news!


#35

Oh, of course…

Woosh


#36

@pharap explanation: your PC has several network interfaces (ethernet, wlan, dial-up…). I had installed network monitoring software for following network packets. One of them created a localhost loopback adapter that shows up as a regular network interface in the OS. What happened is the clients were using that one to send the packets. On a windows PC, if you do ipconfig on the command line, you see that each one of the network interfaces has a different IP. Different IP = wrong address.


#37

Hehe heh :stuck_out_tongue: hahaha :sunglasses:

I’m now at the point where text from one computer is routed instantaneously through a server in US back to another computer on my table. Happy.

What shall we do first? Pokitto chat using @drummyfish 's LIL? A MUD ?


#38

Noughts & Crosses! :P

Seriously though, if you use the version with joyhat support and write a NetworkController then it shouldn’t be too hard to get working.

If I had an example of what the networking code looks like on the Pokitto I could write it myself (though I couldn’t promise it would be bug free since I’d be working blind).


#39

There is no networking code as a class yet. I’m simply routing signals at this point.

The client-server NAT problem was the biggest problem to tackle.

I am now making the client (Win/Mac/Linux) that handles the comms between Pokitto and the server.

Eventually you will be able to roll and run your own server, the client is just a means of converting serial to ethernet.

If you want (and would be much appreciated) you could already make a network class that pretends it is sending and receiving data, with a dummy send and poll methods. We can then hook those up to the client.

Edit: actually lets be a bit more specific

The network connection code needs the following methods:

  • connect (to the server)
  • disconnect
  • isConnected ?
  • write data
  • check for data (poll)
  • read data to a buffer

… and that’s pretty much it.


#40

How does this work physically?
The pokitto needs to be connected to a computer via a usb cable?