Jump to content
  • Advertisement
Septopus

Pub/Sub for game Servers... Are you?

Recommended Posts

Thanks @Hodgman! for your reply.. for some reason this crappy forum software wouldn't even let me thank you without frustration...  dont't let me get into how many times I tried to write that sentence..

5 hours ago, hplus0603 said:

The Erlang solution got started in 2010 or so, and shipped for real in ... 2012? It's still going strong and doing its thing, so I don't think it's "older technology." It's seen at least one major upgrade, to add redundancy in places it didn't have it. (Btw, I think the WhatsApp team is almost entirely on Erlang)

It really is an example of "horses for courses."

So, you're actually saying it works then... ;)

 

Edited by Septopus
too much to drink....

Share this post


Link to post
Share on other sites
Advertisement

Honestly.. "horses for courses"???  when I looked it up it said it meant "to each their own" but I'm really not sure that's what you were saying...  Crossbar???

 

Share this post


Link to post
Share on other sites

@Hodgman...  Your link?
"we took several recent graph-processing publications from the systems community, and compared the measurements they report to simple single-threaded implementations running on my work laptop (RIP)"  Dude, I'm almost 40 and I've been working up to my neck in tech since before I could talk to girls..  What the h.e.-double-hockey-sticks is this first sentence/the first paragraph/the first page saying?  Really?

graph-processing?

Systems community?

single-threaded implementations of what??

 

 

Edited by Septopus

Share this post


Link to post
Share on other sites

I mean really, I spent 13 years in the trenches of ISP Systems Engineering supporting clients with teams of super smart coders.. They all ended up using some kind of UDP or TCP based netcode that did the job... Whatever black magic they think they were doing, it all boiled down to some kind of upd or tcp connection traffic that WE still had to manage FOR them... no matter how clever their internal workings really were.. 

Your limits are never what you perceive, because your perception is your only limit.

Share this post


Link to post
Share on other sites

"horses for courses" also means "choose the right tool/engineer/solution for the job."

(There are some other sayings that are more colorful on that topic.)

Quote

you don't think that something that shipped in 2012 isn't older tech?

Everything cool in computers today was probably invented by IBM for mainframes in the '70s.

Virtual machines? Check.
Container deployments? Check.
RISC? Check.
Message queueing systems? Check.
Untyped prototyping scripting languages? No, that was invented in the '50s.

Six years might feel like a long time in an area like, say, front-end JavaScript frameworks, where the platform you're building on, and the businesses doing the building, all evolve daily, because they're not settled yet. Physical networking, however, has had a lot more development going into it. It's not like the fundamental differences between TCP and UDP, or the use-cases they were designed for, have suddenly changed, because the speed of light or the propagation of electricity in wires seem to be exactly the same now, as then :-)

So, crossbar. comes from electric engineering, where it's a "matrix" or "patch panel" that lets you connect any thing to any other thing. I've often seen it used for various kinds of rendez-vous primitives, such as the bottom level of a message queue broker implementation.

Share this post


Link to post
Share on other sites

Lol, thanks @hplus0603!

My point is, implementation possibilities change month to month these days.  To think that anything designed 6+ years ago is still the state of the art is naive in my perception.

You're right that the physics or the core ideas don't change much or at all.  But implementaions DO.  Newer methods make entire systems behave differently. 

You can't say something you tested last year Will still test the same this year. When you are talking about anything that relies on the internet.  You just can't.

The speed of light or the poropogation of electricity is not at all the actual limiting factor in internet systems.  Regardless of how fast the light moves you can always get new next gen hardware that aggregates MORE bandwidth.  That is what ISPs do on very regular basis.  And every time one of them does that the internet changes just a little bit.  Latencies of effected network segments change, rtt changes.  The entire dynamic changes.

Just because the concepts were born a long time ago doesn't mean the way they work is still the same.

Share this post


Link to post
Share on other sites

@Hodgman I think I'm making some more sense out of your link today.. still not sure, but I think you're trying to say that I should be weary of the overhead I'm creating..  Make sure that my solutions aren't creating more problems.. that kind of thing..  Gotcha.

I think I'm smelling your fire. ;) 

I get that any change from a "single threaded" approach to anything WILL add overhead.  I've accepted that fact.  I'm designing my system without a "central simulation" because the overhead of splitting that kind of mechanism into many different parts would be almost impossible for me to engineer around.  Instead of the single central simulation, there will be many nodes on the network that can interact with players in real-time.  The clients will be the physics processors and collision detectors.  The servers will orchestrate synchronizing the interactions between game entities and make corrections to game entities that risk breaking the illusion of multi-player interactions.

My game/system is a different kind of thing.  I'm not just trying to mimic or improve on existing systems/methods, I'm trying to engineer a different one.

And I'm probably a bit naive in some of my approaches, and that's fine too, because I'm learning lots, and it doesn't take me long to re-gear when things don't test out the way I'd like. ;)

Edited by Septopus

Share this post


Link to post
Share on other sites
Quote

My point is, implementation possibilities change month to month these days. 

I think you don't have enough experience yet to realize that, the more things change, the more they stay the same.

Yes, Redis wasn't available in 2010. But, you know what? Redis can't magically do something that code written in 2010 couldn't. You had to do a little more yourself, but given the primitives available in Erlang, not a lot more. And the solution in Erlang scales horizontally with adding more nodes, whereas Redis does not (Redis Cluster is a joke, technically speaking.) (Yes, you can do application-level sharding for particular use cases.)

Quote

My game/system is a different kind of thing.  I'm not just trying to mimic or improve on existing systems/methods, I'm trying

 to engineer a different one.

If you have a specific kind of game that you want to build, with specific use cases and requirements that aren't met by existing technology, you may be on to something!

If you're just trying to "build a system," without any kind of strong evolutionary pressure on the features and implementation of that system, then experience (not just mine!) says you won't build something that's all that useful. The reason is that many billions of dollars, and tens of thousands of man years are spent on networked games every year, and the market will already have explored most implementation nooks and crannies for the kinds of games that have already been generally funded and delivered. It doesn't matter if it's games, financial trading, car maintenance or movie production -- if there's already a large market, and you don't really have a very specific use case that's not currently served by the market, then you're quite likely not going to make something successful.

Or to put it another way: Do things differently, is not particularly compelling and generally don't build successful projects. Do different things, is where it's possible to truly innovate and push the envelope of what's possible. And sometimes, you need to do things differently to be able to do the different things, but it's the different things that are the reason you win.

That being said, building systems is fun and educational. As long as you learn the right lessons, and draw the right conclusions, testing a bunch of things and pushing them until they break is always a good way of gaining more experience. After all, good choices come from experience, and experience comes from bad choices 😄

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!