4 ms·

If you are writing a game server with web, mobile and desktop clients, is socket.io the way to go? AFAIK, socket.io is a wrapper around websockets. This makes

If you are writing a game server with web, mobile and desktop clients, is socket.io the way to go? AFAIK, socket.io is a wrapper around websockets. This makes it unsuitable for some fast paced games with alot of players. Is there a library which abstracts away tcp and udp connections? And what can you do about tcp attack vectors? Are lamers trying to take down servers a real threat? How do you prepare for this? I therefore advise against writing your own network stack if you intend to make the service available to the public. Or am I too cautious?

synthmeat 9y ago
> If you are writing a game server with web, mobile and desktop clients, is socket.io the way to go? Socket.io's most discerning feature was fallback to polling. There's also some useful abstractions there, like reconnecting, rooms, as well as some useful ecosystem around it, like socket.io-redis adapter which enables you transparently scale horizontally. If your time is at premium, you might find socket.io work for you, but it's not really hard to write everything better yourself, and better tuned to your use-case. > AFAIK, socket.io is a wrapper around websockets. This makes it unsuitable for some fast paced games with alot of players. For fast-action multiplayer, there's currently no sensible offering besides WebRTC's DataChannel, with all it brings on board (I've yet to study it in-depth). I'm having high hopes for QUIC to gain more ground. > And what can you do about tcp attack vectors? Are lamers trying to take down servers a real threat? From what I've experienced first hand, bots/scripts are most frequent enjoyment-spoiler for other players. I've never ran at scale where I'd be interesting target for actual attacks.
gfysfm 9y ago
As for udp connections, WebRTC looks like the only mature solution (but it's not designed for games and is way more complicated than game devs want it to be). Alternatively, I know about https://github.com/networkprotocol/netcode.io https://github.com/networkprotocol/netcode.io but it's very much in the early stages - afaik you even need a Chrome extension to use it on the client. It's not easy to do udp on the web.
- lxtx 9y ago
  An "UDP" server for browser clients: https://github.com/seemk/WebUDP https://github.com/seemk/WebUDP
  - gfysfm 9y ago
    Cool, thanks. I'll try this out if I ever want to switch to WebRTC.
  - emj 9y ago
    I get 60ms RTT for the largest bin of packets with WebUDP many requests goes as high as 140ms (positive skew of the distribution), while ICMP never goes above 29ms RTT. I know UDP can be badly prioritized in some networks but I don't think it can only be that... This needs more investigations imho, I wonder where this fails so badly; is WebRTC aiming at ~100ms latency?
    - lxtx 9y ago
      Definitely a bit weird. Where are you located? The echo demo server is hosted in the Netherlands. That's how the round trip histogram looks for me in Estonia: https://i.imgur.com/iBoqwe4.png https://i.imgur.com/iBoqwe4.png I'll take a look later if there's any noticeable delays caused by the server.
      - emj 9y ago
        I left it running for some hours and got alot more 30ms responses: https://imgur.com/a/SdWtc https://imgur.com/a/SdWtc
        emj 9y ago
        Chrome use ~100% cpu transceiving ~83 packets per second, and I think it sends packets at a slower rate later on, that's why we get so many 30ms responses when we wait some hours. This is a tcpdump after loading the page: \time sudo tcpdump -c 1000 -ni eth0 udp and port 9777 1000 packets captured 1000 packets received by filter 0 packets dropped by kernel 0.02user 0.05system 0:12.45elapsed 0%CPU (0avgtext+0avgdata 5472maxresident)k 0inputs+8outputs (0major+1508minor)pagefaults 0swaps This is just a flood ping, interesting that the UDP version shoots more packets. \time sudo ping -f -c 1000 188.166.46.128 PING 188.166.46.128 (188.166.46.128) 56(84) bytes of data. .... --- 188.166.46.128 ping statistics --- 1000 packets transmitted, 996 received, 0% packet loss, time 14195ms rtt min/avg/max/mdev = 28.839/38.641/50.433/5.152 ms, pipe 5, ipg/ewma 14.209/41.787 ms 0.02user 0.13system 0:14.31elapsed 1%CPU (0avgtext+0avgdata 2248maxresident)k 0inputs+8outputs (0major+1183minor)pagefaults 0swaps

synthmeat 9y ago

> If you are writing a game server with web, mobile and desktop clients, is socket.io the way to go? Socket.io's most discerning feature was fallback to polling. There's also some useful abstractions there, like reconnecting, rooms, as well as some useful ecosystem around it, like socket.io-redis adapter which enables you transparently scale horizontally. If your time is at premium, you might find socket.io work for you, but it's not really hard to write everything better yourself, and better tuned to your use-case. > AFAIK, socket.io is a wrapper around websockets. This makes it unsuitable for some fast paced games with alot of players. For fast-action multiplayer, there's currently no sensible offering besides WebRTC's DataChannel, with all it brings on board (I've yet to study it in-depth). I'm having high hopes for QUIC to gain more ground. > And what can you do about tcp attack vectors? Are lamers trying to take down servers a real threat? From what I've experienced first hand, bots/scripts are most frequent enjoyment-spoiler for other players. I've never ran at scale where I'd be interesting target for actual attacks.

gfysfm 9y ago

As for udp connections, WebRTC looks like the only mature solution (but it's not designed for games and is way more complicated than game devs want it to be). Alternatively, I know about https://github.com/networkprotocol/netcode.io https://github.com/networkprotocol/netcode.io but it's very much in the early stages - afaik you even need a Chrome extension to use it on the client. It's not easy to do udp on the web.

lxtx 9y ago
An "UDP" server for browser clients: https://github.com/seemk/WebUDP https://github.com/seemk/WebUDP
- gfysfm 9y ago
  Cool, thanks. I'll try this out if I ever want to switch to WebRTC.
- emj 9y ago
  I get 60ms RTT for the largest bin of packets with WebUDP many requests goes as high as 140ms (positive skew of the distribution), while ICMP never goes above 29ms RTT. I know UDP can be badly prioritized in some networks but I don't think it can only be that... This needs more investigations imho, I wonder where this fails so badly; is WebRTC aiming at ~100ms latency?
  - lxtx 9y ago
    Definitely a bit weird. Where are you located? The echo demo server is hosted in the Netherlands. That's how the round trip histogram looks for me in Estonia: https://i.imgur.com/iBoqwe4.png https://i.imgur.com/iBoqwe4.png I'll take a look later if there's any noticeable delays caused by the server.
    - emj 9y ago
      I left it running for some hours and got alot more 30ms responses: https://imgur.com/a/SdWtc https://imgur.com/a/SdWtc
      - emj 9y ago
        Chrome use ~100% cpu transceiving ~83 packets per second, and I think it sends packets at a slower rate later on, that's why we get so many 30ms responses when we wait some hours. This is a tcpdump after loading the page: \time sudo tcpdump -c 1000 -ni eth0 udp and port 9777 1000 packets captured 1000 packets received by filter 0 packets dropped by kernel 0.02user 0.05system 0:12.45elapsed 0%CPU (0avgtext+0avgdata 5472maxresident)k 0inputs+8outputs (0major+1508minor)pagefaults 0swaps This is just a flood ping, interesting that the UDP version shoots more packets. \time sudo ping -f -c 1000 188.166.46.128 PING 188.166.46.128 (188.166.46.128) 56(84) bytes of data. .... --- 188.166.46.128 ping statistics --- 1000 packets transmitted, 996 received, 0% packet loss, time 14195ms rtt min/avg/max/mdev = 28.839/38.641/50.433/5.152 ms, pipe 5, ipg/ewma 14.209/41.787 ms 0.02user 0.13system 0:14.31elapsed 1%CPU (0avgtext+0avgdata 2248maxresident)k 0inputs+8outputs (0major+1183minor)pagefaults 0swaps