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!


hplus0603

Member Since 03 Jun 2003
Offline Last Active Yesterday, 08:36 PM

#5230872 What services do cloud providers give to customers

Posted by hplus0603 on Yesterday, 12:04 PM

AWS gives you mainly a blank slate. You could try pushing game data through services such as SQS or Lambda, but those services really are not intended for game-style use cases -- they work best for bigger, less frequent, less real-time sensitive events.

In general, the N-squared problem of "every player could interact with every other player in a town square" is the biggest technical challenge in an MMO. Solving that requires a careful attention to game design together with technology. Many games have died because they don't get it right -- either the design is not really technically achievable, or the tech drives design to the point where the game is generic and boring.

Thus, most MMOs can make a good argument for needing at least partially custom network code, because it's so core to the final experience.


#5230468 Client side hit detection vs server side with prediction

Posted by hplus0603 on 22 May 2015 - 02:22 PM

It is easier to write, which is sometimes an important trait.
Also, server rewind may still suffer from dropped/delayed packets, where the server comes to a different conclusion than the client.
If you use client-side hit detection, the client will "never" have the feeling of lag (but may, instead, have the feeling of someone else shooting them when they feel they alread dove into cover.)


#5229617 NitroNet - New, High-Level Networking Library

Posted by hplus0603 on 18 May 2015 - 11:03 AM

they're not going to stop me from continuing development on NitroNet


I hope I didn't sound like I suggested that you should! We learn by doing, measuring, and repeating.
Glad to see you're finding value in this project.


#5229616 NitroNet - New, High-Level Networking Library

Posted by hplus0603 on 18 May 2015 - 11:02 AM

It is?


I think so. JNI's pretty reasonable, as far as interoperability goes. Not as nice as P/Invoke, or the Haskell FFI, but better than Lua or Python or such.


#5229524 NitroNet - New, High-Level Networking Library

Posted by hplus0603 on 17 May 2015 - 09:16 PM

Also yes I spawn a new thread for each TCP connection and kill it when the connection leaves.


This is a big draw-back of any networking library. For 8 players, it's probably OK. For a server with hundreds, or thousands, of active players, it's a big no-no. I'd hope that every modern networking library would use evented I/O and worker threads, rather than thread-per-socket. (Look at the nio library in Java, for example.)

Im sorry, I dont understand how exactly it would defeat the checksum protection by allowing them to modify the bytes. The checksum will always try to be received regardless of whether or not someone modifies the bytes.


If your protocol doesn't address client and server authentication (using private/public keys,) message digest authentication (using a cryptographic message digest and negotiated key,) initialization vector management (which may add payload the the underlying stream,) and session key negotiation (which probably should use Diffie-Hellman or similar,) then you're probably better off just not mentioning encryption.

Also, any C/C++ library can be ported and run on any environment (iOS, Android, Windows, MacOS X, Unix, Blackberry, Symbian, Bada, Xbox, Playstation, Wii, ...) The same cannot be said for Java; there exists platforms where no good Java runtime environment exists for user-defined code. It's also pretty easy to wrap a C/C++ library in JNI and call it from Java. The reverse cannot be said.

So, again, thank you for giving a reference to your library. I probably won't include it among the "recommended set," though, given the weaknesses suggested above, given that the other options are significantly more robust and implemented in a context of more experience of real networking challenges.


#5229397 NitroNet - New, High-Level Networking Library

Posted by hplus0603 on 16 May 2015 - 09:47 PM

Thanks for pointing out your library.

Could you go into a little more detail about how it compares to other common open source networking libraries?

* RakNet

* boost::asio

* ZeroMQ

* ENet

Most of those libraries have been used for larger projects than the ones you're currently suggesting, so choosing a new library has to be done for some significant and obvious benefit. What would you say your benefit is? How did you achieve/implement that benefit, compared to the others?


#5229396 How do I make a dedicated server for mobile game?

Posted by hplus0603 on 16 May 2015 - 09:44 PM

Actually, most "social" games do not need a real-time simulator. Instead, they send the parameters for the game to the player; the player then interacts with the "event" (invasion or whatever,) and then sends back the commands the player issued and the results to the server. The server re-plays the game given the player commands, and verifies the results, after which the world state is updated.

Thus, you really don't need anything more than a basic HTTP application server to implement this kind of gaming. The most important part is being able to write the game-logic in the same language on the client and on the server, so that commands/interaction done on the client ends up being the same on the server. The four most obvious technologies for this are:

* C/C++ -- you can write servers in C/C++, and you can write clients in C/C++, and that C/C++ code can be ported to all platforms. Definitely the "least strange" way of doing it, although of course you'll have all of the draw-backs of C/C++ development,too.

* Java -- you can write servers in Java easily; and you can still write clients in Java (such as Minecraft,) although the support on client devices is going away -- you may have to embed a Java interpreter in your binary for some platforms, and some platforms don't allow JIT compilation for user-supplied code, which would make it run slow. This is currently a possible path, but I wouldn't bet on it being free of heart-ache in the future.

* C#/Mono -- write server and client code in C# (or another .Net language) and deploy on top of Microsoft .Net for the Windows-based platforms, and on top of Mono for the others. Mono is not as high quality as .Net, and you have to test with both implementations to make sure what you develop will actually work. Ahead-of-time compilation (a la NGen) makes shipping binaries to restrictive environments easier (Unity does this for iOS, for example.)

* JavaScript -- write the game to run in a browser; run the same code on the server with a JavaScript application server like Node.js or a fork thereof (io.js)

If I want to install the game or download it from an app store, I'd probably personally go with C++; C# would be second place.

If I want to play in a browser, JavaScript would be the obvious choice. However, there are ways to compile C++ to JavaScript (such as emscripten) that could make C++ work there, too.


#5229395 Multiplayer to an existing game?

Posted by hplus0603 on 16 May 2015 - 09:37 PM


It's not easy, or fun, but it's possible



It's not easy, true. Some people think it's fun, though! In fact, that's almost the only reason someone would spend every night for months (or years) to do it, because there's no money in doing so...

In my experience, you don't just need "a few" years of reverse engineering and systems programming experience; I'd say that you need ten years of programming experience (most of it with C, C++, and/or assembly) as well as knowledge how to use more low-level debuggers like WinDBG and such.


#5229068 IOCP AcceptEx is Not Updating IOCP Queue.

Posted by hplus0603 on 14 May 2015 - 09:30 PM

First:

assert(listen(listen_socket, 256) == 0);
In non-debug builds, this code will not execute. You should never put code with wide effects inside an assert()!

Second:

	Network::Initialize();
	CreateListener(listen_socket);
	LoadFunctions(listen_socket);
What does Network::Initialize() do?
What does CreateListener() do?

Why do you ask the socket implementation for functions, instead of using AccetptEx() from mswsock.lib?
That is a rather poorly conceived extension that adds a fraction of one thousandth of one percept of performance to a typical application; it's only there for benchmark purposes on 20 year old systems.

static DWORD WINAPI WorkerThread(void* parameter)


Your threads will likely start and run into errors before you create the I/O completion port.
That's likely the actual problem in the above code snippets, but all of the other thing are questions, too.

auto& it = std::find(clients.begin(), clients.end(), info->client_socket);


"clients" is not synchronized between threads.

get_accept_ex_sockaddrs(info->buffer.buffer,
				            info->buffer.size,
				            sizeof(sockaddr_in) + 16,
				            sizeof(sockaddr_in) + 16,
				            reinterpret_cast<sockaddr**>(&local),
				            &locallen,
				            reinterpret_cast<sockaddr**>(&remote),
				            &remotelen);
AcceptEx() already returns the addresses into the original buffer; there is no need for this call.

Quoth MSDN on AcceptEx():

the addresses are written to the latter part of the buffer



I find the Windows I/O Completion Port and OVERLAPPED I/O system to be somewhat byzantine in design, but actually well documented and works as advertized.

If you want a simpler, still very efficient, wrapper for sockets, that works on both Windows and other platforms, I would recommend boost::asio.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms737524%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363862%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364986(v=vs.85).aspx


#5229049 Client side prediction

Posted by hplus0603 on 14 May 2015 - 06:28 PM

You generally don't want to use a different tick rate between server and client.
You generally want a single, fixed, tick rate for your simulation.

You *can* build various architectures where the server might simulate, say, at 10 Hz, and the client simulates at the same rate as display frame rate, but then you will forever fight problems where simulations are stable on one side but not the other.
Depending on how much physics you use, this may or may not be manageable.

As an example: How high you jump when given an impulse of a particular size varies by the size of the physics step rate, if you use a typical first-order gravity simulation.


#5228797 Client side prediction

Posted by hplus0603 on 13 May 2015 - 09:37 AM

It would be interesting to know, for diagnostic purposes, whether the cause of the jumpiness is that the server comes to a different simulation result than the client, or whether the cause is someting in your forwawrd playback.

Do you save the simulated state for time period X, and compare to what the server sends you back?


#5227650 UDP sockets size and speed question

Posted by hplus0603 on 06 May 2015 - 09:16 PM

You're correct in pointing out that, when I say:

(IPv6 doesn't fragment, but guarantees a minimum MTU of 1200 bytes)


I mean that the intervening nodes (routers) will not do fragmentation -- there's nothing preventing an IPv6 software stack on the sending end to implement this before it hits the network.

It is possible for the sending node to do path MTU discovery and use the Fragment extension. This is possible for an intermediate software layer to do, to support larger UDP datagrams, rather than limit the size of UDP datagrams. The way I read the spec, this is "strongly recommended" but not guaranteed.


#5227430 UDP sockets size and speed question

Posted by hplus0603 on 05 May 2015 - 10:31 PM

First: "packet" not "package."

 

Second, the maximum size of a packet depends on protocol and hardware.

The maximum size of a UDP datagram is 65507 bytes on IPv4.

On most networks, that will fragment into IP datagrams of size 1452, or 576, or 9000, or ... and be reassembled on the receiving side.

(IPv6 doesn't fragment, but guarantees a minimum MTU of 1200 bytes)

 

http://en.wikipedia.org/wiki/Maximum_transmission_unit

 

Third, transmission speed depends on speed of signal/light/electricity, speed of routing, and throughput of the narrowest link.

 

If your ping time is X and your throughput is Y and your packet is size Z, an estimate for transmission time is X/2+Z/Y.

 

This does not take into account buffering, interrupt latency, and game simulation delay.




#5226711 Alternative to NewRelic?

Posted by hplus0603 on 01 May 2015 - 09:26 AM

For host and application real-time metrics, we use istatd. (We have to run the host ourselves, of course.)

https://github.com/imvu-open/istatd

Having 10-second-granularity data is very helpful when trying to figure out which came first: an increase in load or a decrease in throughput or whatever.


#5226533 networking solutions for making MMO

Posted by hplus0603 on 30 April 2015 - 10:33 AM

@whiplash: For a better answer from the forums, you need to answer the questions that I posted in #5: http://www.gamedev.net/topic/667655-networking-solutions-for-making-mmo/?view=findpost&p=5224200




PARTNERS