Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Dave Weinstein

Member Since 08 Mar 2006
Offline Last Active Jan 29 2015 08:14 AM

#5046976 Client - non dedicated server architecture

Posted by Dave Weinstein on 26 March 2013 - 12:10 PM

You need to be clear on your terminology:

Peer-to-Peer is a network architecture. You are discussing a client-server architecture, so there is no "peer-to-peer" here.

Dedicated server versus server-with-local-player is an implementation issue.

Consumer-hosted versus Publisher-or-Developer-hosted is a business model.

If you have a lobby server or master-server list in the clear, it can do NAT tunneling for you, so there is no need for someone to have a firewall setup correctly.

#5044263 Sending structures through UDP sockets

Posted by Dave Weinstein on 18 March 2013 - 10:57 AM

That usually flies in the face of object oriented programming in many ways , but if you MUST have the speed to make the game work the choice is simple.


Direct binary "globbing" makes sense for level-load, where seek time can kill you.


But the amount of time spent unpacking game messages is a rounding error on a rounding error of your frame rate; you are better off making the code readable and maintainable. Moreover, for network traffic, you are going to have to validate all the messages anyway, so you don't gain even that minuscule speedup



#5042476 Multiple Sockets Per Client

Posted by Dave Weinstein on 12 March 2013 - 04:18 PM

Rainbow Six and Rogue Spear used a hybrid TCP/UDP model for networking.


All combat traffic and a reliable movement strobe (1hz for all entities in the game world) went out via TCP. UDP packets handled interstitial movement packets for entities that were determined to be "near" the player.


There are some distinct advantages to this:


1. Writing an efficient ordered/reliable transport layer on top of UDP is not a trivial task.

2. With an ordered/reliable transport layer you get de-facto delta compression on your traffic. Since the key to network game design is knowing what data not to send, and how often to not send it, this is a big win.

3. At the time, a significant percentage of the player base were still on modems. While the UDP header is 28 bytes versus 40 for the TCP header, with header compression (which is supported on TCP but not UDP for historical reasons), that drops down to 5 bytes or so.


You'll note that the key points there were code complexity and bandwidth reduction. All ordered/reliable traffic (TCP or roll-your-own) has a known issue, which is "hitching". If a packet in the middle is lost, you need to hold the later packets which have arrived until the middle packet has been resent. 


Later generations of Red Storm games (starting with Ghost Recon 2, if I recall correctly) had everything rolled up into a custom protocol over UDP that handled unreliable, ordered/reliable, and reliable-but-unordered traffic. 


The reason had nothing to do with TCP per-se, and everything to do with the change in the consumer environment. By that point in time, a significant percentage of the customer base were behind NAT. It is fairly straightforward (assuming you have a matchmaking service) to bypass NAT over UDP, and impossible to do it with TCP without having the players set up port forwarding for the server. 


With all that, my recommendation would be to find a well-tested library that does what you need over a combined reliable/unreliable protocol on top of UDP, and use that. As a general rule, unless you are a very experienced network developer, you should not be implementing your own reliable layer on top of UDP, it is too easy to get wrong.

#5036375 TCP Server NetworkModel for MUD

Posted by Dave Weinstein on 25 February 2013 - 11:10 AM

I'm wondering why message overlap is even a problem in a TCP stream? The data is always in order and guaranteed.

TCP data is always in order and guaranteed, this is true. TCP is, however, a stream, so what is not guaranteed is data grouping.

Let us say that I generate 5 50-byte logical packets. Each is sent during a separate frame.

I could get all five at once (a single 250 byte blob). I could get 250 one byte receives, I could get anything in between.

This is why we need some kind of framing in the logical packet itself; there is nothing in the TCP stream that does it for us because there is no guaranteed correlation between the number and size of TCP sends and the number and size of the corresponding TCP receives.

#5033916 Is marketing a practical major like computer science and buisiness?

Posted by Dave Weinstein on 18 February 2013 - 04:23 PM

I am more leaning towards concept art as i have been doing fanart with Sonic characters for awhile.


The number of concept artist positions in the industry as a whole is miniscule. You may need a dedicated concept artist, you will need lots of content creation artists.


So, as a good rule of thumb, if you are not so successful in another medium that a game company is licensing your IP or your name/fan-base, you will need to be a successful production artist before you can get a job as a concept artist.