Jani_Nykanen

Last Login:
August 23, 2017
Warn:

Rank:
Member



User Profile
Follow

Hits: 64,813
Joined March 07, 2014
Games (5)

A Journey to Eternity
July 24, 2016
Operation Fungus
December 14, 2015
The Last Minute Dungeon
December 12, 2016
The End
June 27, 2017
Flying Cat Stomper
July 26, 2017


Networking
Posted on February 04, 2017 at 14:19

Look at this thing:



See, I managed to write a working chat application! Woohoo! It did require a lot of work, mostly because I wasn't familiar with fancy concepts such as "multithreading" or "networking". Sure, I had had experiments with both these things, but I never succeeded to get these things working properly. Until now.

The server-side uses node.js. Reason(s): 1) Handling multiple sockets and receiving and sending data and such in C++ turned out to be a bit too difficult to me, so I decided to make my life easier and write only the client in C++. 2) I'm pretty sure it's easier to find good (virtual private) server that allows me to run node-js scripts than a server that allows me to build a C++ application and run it without too much hassle.

The client side is written in C++, like stated above, and it uses Sfml for networking and SDL for graphical interface.

I'm going to turn this chat application into a game one day. Maybe not a full game, but a game where you can move rectangles and see other people's rectangles moving. That means I have to add support for UDP sockets (the chat uses TCP). Sure, I could handle real-time game events data using TCP sockets if I found a good way to hide the latency, but... I rather not. Most games use both UDP+TCP/IP, so of course I want to be like "most games".

Since I'm using node.js in server-side and C++ in client-side, it means I have to write the game logic twice in two different languages. I'd better keep things simple, then.

The most important thing I learned while making this ultracomplex network application was multithreading: it's powerful and very, very useful technology, but also requires you to know what you are doing, or soon you'll find yourself blocking the whole program by misusing mutexes.

Nothing else this time, don't try to stay alive until the next update (then you can die).


Well done.... Will you integrate it into your games in the future???
Posted by mrpete February 04, 2017 15:42 - 6.7 months ago
| [#1]

Woo, networking is fun. It's probably what I play with most anymore.

Quote
good (virtual private) server

Vultr is really good and cheap. They're hourly so if you're just testing something for a short while you're not paying a full month. I used to use Digital Ocean but I've found Vultr to be better for the money.

Quote
if I found a good way to hide the latency

Disabling Nagle helps, which means enabling the TCP_NODELAY flag.

Quote
Most games use both UDP+TCP/IP,

Mixing both UDP and TCP can actually be harmful. I mean for most things it'd probably be okay, but it's worth mentioning. I think you'd be better off just using UDP alone. It's not too hard to make your own "reliability" system for UDP datagrams.

Glenn Fiedler has a lot of interesting posts on his site about this stuff that you might be interested in.
Posted by Cpsgames February 04, 2017 17:19 - 6.7 months ago
| [#2]

Quote
Mixing both UDP and TCP can actually be harmful. I mean for most things it'd probably be okay, but it's worth mentioning. I think you'd be better off just using UDP alone. It's not too hard to make your own "reliability" system for UDP datagrams.

I'm pretty sure I read somewhere it's recommend to use both, but now with further reading, many sources claim that one should use either to avoid packet losses etc.

Conclusion: I'd better rewrite the entire code to use UDP (or RUDP, "Reliable User Datagram Protocol", although I'm not sure how widely it is supported in programming languages...). Since my old code was already a mess, that's not a problem.
Posted by Jani_Nykanen February 05, 2017 3:19 - 6.6 months ago
| [#3]

Recent Activity
 
Active Users (0)