Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


Member Since 03 Jun 2003
Offline Last Active Today, 05:20 PM

#4997019 Networking Backend, spending

Posted by hplus0603 on 03 November 2012 - 05:58 PM

Well, anywhere from a few thousand to a few hundred thousand, depending on what you mean by "network backend" and how willing you are to compromise on requirements.

There are also sites like elance and vworker (formerly rentacoder) which can do various kinds of work, but the important part is that you have to have a very clearly defined specification. If you can write up "here are the interfaces you have to implement, and here's what they have to do, and this is the amount of resources (time, memory, CPU, networking bandwidth, etc) that you may use" then you'll be in a much better place to outsource a particular component like this.

You might also want to look at existing back-ends. There are free ones, like Enet, and indie-free ones, like RakNet. Both of those are C/C++. I forget what language you're using -- C#/.NET has Lidgren, while Java doesn't have as much that's game-oriented that I can think of.

#4997017 Network programming strategies. Any tutorial?

Posted by hplus0603 on 03 November 2012 - 05:54 PM

There are as many networking systems as there are game genres, because each kind of game needs different compromises in data model richness, accuracy, throughput management, and latency compensation.

Yes, it's totally fine to keep a queue of events to send on one end, send them all as one packet every so often, and then put them in a queue of events to dispatch/deal with on the receiving side. Many games work like that. If you're using TCP, beware that you have to put a length field before each "packet" that you send, because the TCP connection may/will split your send() calls into multiple recv() calls and/or combine multiple send() calls into a single recv() call.

#4994822 Network programming

Posted by hplus0603 on 28 October 2012 - 01:52 PM

Beej's networking tutorial is a general-purpose sockets tutorial. It's linked from the FAQ.


Also, if you're a C++ programmer, you may prefer the boost::asio library, which I think is better in a few ways:
1) It's asynchronous (and I just like that :-)
2) It's higher performance than plain select() sockets
3) It's fully portable -- select() and sockets require some #defines or #ifdefs on Windows

The boost::asio library has some good examples no the proper boost site, BUT it doesn't have a "networking" tutorial -- it assumes you know what an IP address is, how it's different from a port number, etc.


#4994614 How to make cURL reconnect

Posted by hplus0603 on 27 October 2012 - 08:23 PM

If I remember right, once a connection is dead, you have to create a new one. So, try that. It's been a while since I used libcurl, so the details are fuzzy.
The HTTP protocol (version 1.1) allows a single TCP connection to be re-used for multiple HTTP requests, but once that TCP connection is dead, you cannot re-use it.

#4994544 How to make cURL reconnect

Posted by hplus0603 on 27 October 2012 - 03:56 PM

If you're using HTTP connections, then HTTP does not have "reconnect." You have to create a new HTTP request and start that.

#4993524 Match making question

Posted by hplus0603 on 24 October 2012 - 01:48 PM

Is that enough to ensure fair conditions between players?

You have to define what "fair" means to you. Different players will have different quality graphics cards, CPUs, internet connections, keyboard and mouse, quiet vs noisy environment, good vs bad coffee, etc. Figure out what YOU think "fair" means for YOUR game, and then make it so.

#4993310 Match making question

Posted by hplus0603 on 23 October 2012 - 07:55 PM

Most traditional FPS-es uses player-hosted games.
In fact, often, the single-player game is just a game client connected to a local server that runs the single-player level.

You can deal with the unfair advantage by penalizing the hosting player to get, say, the average latency of all connected players; just delay incoming and outgoing data a little bit for that player.

#4992539 recieving data with sockets

Posted by hplus0603 on 21 October 2012 - 01:56 PM

sizeof(Player) should be sizeof(struct Player)

There is no difference between those two expressions, unless you're using plain C and do not have a typedef for struct Player to Player. And, if you don't have that, then the code wouldn't even compile.

#4992053 recieving data with sockets

Posted by hplus0603 on 19 October 2012 - 11:11 PM

Also: Always check the return value from functions. Especially from send() and recv()!

#4991815 select() in server

Posted by hplus0603 on 19 October 2012 - 10:30 AM

By sleep i didn't mean the sleep function, I meant the OS' sleep state.

It may be a terminology thing. The way I understand it, a thread enters "sleep" state by calling sleep() or similar functions. This is different from the "blocked" or "wait" state which is when a thread is actually waiting on something else to happen.

Also, if you use mutexes in your threads, you won't actually scale across cores, because your threads will end up serializing on whatever the common data structure is. Thus, you can save memory, CPU overhead, and programming complexity by using select() or non-blocking sockets instead of multiple threads for your networking.

#4991814 How much data per second can I allow my engine to send?

Posted by hplus0603 on 19 October 2012 - 10:28 AM

So my clients need roughly 200 kbps down and 10 kbps up. If those speeds can be reached with DSL then I guess that's acceptable. I don't see why the server would need 200 kbps down since the data going to the server is fairly small.

So, if each client needs 200 kbps down, that means that the server needs 200 kbps up per client. Additionally, if the clients send 10 kbps up per client, then the server needs 10 kbps down per client. How many clients? Multiply, and add some safety margin.

FWIW: Residential internet does not make for a good permanent server solution, even if you get a "static IP" from your ISP. The service level just aren't at the level of reliability you get from a co-location or hosting datacenter. There are fairly cheap "full" hardware solutions with significant bandwidth (10 Mbit or so) for $50/month, and you can get similar pricing, including bandwidth, for virtual servers if you can live with the scheduling latency/jitter.

#4991675 Overflowing Buffers!

Posted by hplus0603 on 18 October 2012 - 10:47 PM

Yes, it's usually better to buffer all outgoing messages and send them in one fell swoop when the "tick time" comes. If you ever change to UDP, that's a requirement. For TCP, the OS will do some of that buffering for you, if you do not turn off Nagling (i e, do not turn on TCP_NODELAY.)

#4991673 How much data per second can I allow my engine to send?

Posted by hplus0603 on 18 October 2012 - 10:43 PM

Your client seems to need about 20kbps down, 10kbps up - that's within the range of a decent dial-up connection.

I think you're off by an order of magnitude there ;-) The OP said kB, not kb.

#4991586 How much data per second can I allow my engine to send?

Posted by hplus0603 on 18 October 2012 - 04:49 PM

What sort of connection can you generally expect people to have?

Google for "Steam hardware survey" and "unity3d hardware survey" to find some snapshots of the gameplaying public.

#4991499 A "What's Next" Networking Question

Posted by hplus0603 on 18 October 2012 - 11:58 AM

This is also answered in the FAQ, which says you need a name to look up through DNS, and suggests using dyndns.org or similar to establish and update a name for your dynamic IP.
If you're new to network programming, I suggest you skim the FAQ, because it contains both help for newbies, as well as help for more advanced programmers, and when you get to a particular problem, you may then remember some question from the FAQ, and can go back and look it up there!