JGN vs. Darkstar

Networking & Multiplayer
#41

[quote]RMI: A straw man. It ain’t designed for games. Don’t use it for anything where latency is going to be an issue.
[/quote]
Taken from wikipidea

[quote]Communication lag or latency, the time taken for a packet of data to be sent by an application, travel and be received by another application.
[/quote]
I just wanted to bring this up. So isn’t latency an issue for any game that utilizes the internet backbone for network communication? I read in another thread that 200ms is the average latency for users.

As shown in my loopback example in another thread, RMI has an average of 0.0477ms latency (for sending a message that contains 10 bytes). I haven’t tried RMI across the internet so I don’t know what the average latency is for this (sending across the internet is hard to come up with good numbers b/c there are many variables that change … the best you can do is study over a long period of time to come up with something that is more accurate).

I also will point out that just b/c something wasn’t designed for games doesn’t mean it won’t work or isn’t a good solution (OpenGL is a great instance of this).

So I pose another question to both Darkstar and JGN … How do you mitigate latency?

Also, Jeff, why do you think RMI can’t be used for areas where latency will be an issue?

#42

Conzar, I’ve stated already, there’s nothing stopping you from using RMI for your game development. If that fulfills your needs then that’s great. I think I’ve shown that JGN can be actually easier to use than RMI and it’s designed for game development so you’ll get better performance. I don’t want to argue the validity of RMI for game development, but I will ask why this is even a debate?

I think you’ll acknowledge that both JGN and Darkstar are faster and more reliable for game networking than RMI and why develop using something you know isn’t going to work as well as another option? What benefits do you get from RMI? I haven’t seen a single advantage apart from the fact you’ve already written code for it. If it’s simply trying to justify coding with RMI because you don’t want to rewrite your code then that’s fine. If you are using RMI and it’s not causing you any problems then it’s probably silly to change.

UDP is the primary means for mitigating latency in my game development. You’ve got to realize that there are two parts to lag in games. You have the “actual lag” that is made up of some “issue” that causes data to be delayed getting from one place to another and the “after effects” of that. The after effects are generally as bad or worse than the actual lag. For example, if I am sending 10 messages/second synchronizing the position of an object in 3D space and the connection is lagged. If the delay is 2 seconds, I now have a backup of 20 messages that will still arrive, but 2 seconds late. In addition I have another 10 messages that just got sent. Realistically I shouldn’t care about those 20 messages that are now out-of-date, I just want the new 10 that just got sent. However, before those last 10 can get to me on TCP the first 20 must arrive. This creates significantly more “perceptible lag” because the system has to process those 20 messages in order to get back on track.

JGN deals with this by the use of UDP and RealtimeMessage (I’ve explained this before) so in places where guaranteed delivery is not necessary, neither is the “after effects” of lag. :wink: I try to minimize the number of messages that are sent via TCP to only those that need guaranteed delivery (such as chat messages). The great thing about this is that the majority of game communication doesn’t need guaranteed delivery so it minimizes the amount of traffic being sent via TCP and when lag spikes occur they are much less perceptible.

#43

[quote]Conzar, I’ve stated already, there’s nothing stopping you from using RMI for your game development
[/quote]
With my current project, we have not yet decided on which method to use RMI/JGN/Darkstar. I’m just trying to get a good understanding of the technologies before making that decision. I am not trying to fly any particular flag … I have used RMI in the past and have read through their documentation so I understand their system better then JGN and Darkstar.

I have to ask you guys here b/c JGN’s documentation is non-existant (I know ur 1 guy and no time) and Darkstar has some slides from AGDC that are helpful but still not complete.

btw: sunsett, thanks for the information on UDP/TCP and latency.

As I stated before, I’m not trying to offend nor state who is better. Just trying to get at the facts and try to understand the benefits and detriments of each tech.

#44

That’s fair. I would suggest evaluating your reasons for considering each one and weigh the benefits versus weakness to come up with the right solution. If you plan on doing game development long-term, I really think it’s a mistake to even take into consideration, “I already know how to do this” as a valid benefit. You should focus on finding absolutely the best solution for what you’re trying to accomplish and handle any learning required to get there.

Don’t get me wrong though, I can definitely appreciate your desire to find out about what’s already been written out there. I find it rather annoying how frequently people end up writing their own code to accomplish a task when often they could find something pre-written that can actually do the job better and more efficiently than their code.

#45

Can either Darkstar or JGN do SSL encryption?

#46

SSL is not implemented in JGN, but encryption is fully supported. The only “included” encryption is Blowfish, but implementing additional encryption styles is trivial. As an example, take a look at the Blowfish implementation:

/**
 * Copyright (c) 2005-2006 JavaGameNetworking
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are
 * met:
 *
 * * Redistributions of source code must retain the above copyright
 *   notice, this list of conditions and the following disclaimer.
 *
 * * Redistributions in binary form must reproduce the above copyright
 *   notice, this list of conditions and the following disclaimer in the
 *   documentation and/or other materials provided with the distribution.
 *
 * * Neither the name of 'JavaGameNetworking' nor the names of its contributors 
 *   may be used to endorse or promote products derived from this software 
 *   without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 * Created: Oct 7, 2006
 */
package com.captiveimagination.jgn.translation.encryption;

import java.security.*;

import javax.crypto.*;
import javax.crypto.spec.*;

import com.captiveimagination.jgn.translation.*;

/**
 * @author Matthew D. Hicks
 */
public class BlowfishDataTranslator implements DataTranslator {
	private Cipher encrypt;
	private Cipher decrypt;
	
	public BlowfishDataTranslator(byte[] key) throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException {
		SecretKeySpec skeySpec = new SecretKeySpec(key, "Blowfish");
		encrypt = Cipher.getInstance("Blowfish");
		encrypt.init(Cipher.ENCRYPT_MODE, skeySpec);
		decrypt = Cipher.getInstance("Blowfish");
		decrypt.init(Cipher.DECRYPT_MODE, skeySpec);
	}
	
	public byte[] inbound(byte[] bytes) throws IllegalBlockSizeException, BadPaddingException {
		return decrypt.doFinal(bytes);
	}

	public byte[] outbound(byte[] bytes) throws IllegalBlockSizeException, BadPaddingException {
		return encrypt.doFinal(bytes);
	}
}

DataTranslators allows byte level data translation of message data before sending and receiving. This is useful for encryption, compression, and any other arbitrary data conversion you may want to do.

#47

Darkstar has a plugable transport layer, so it could be done, but I don’t know if anyone has yet.

HTH

Endolf

#48

SSL encryption and decryption on a heavyduty 10000-connection server?

How on earth would that perform reasonably. Even zip-compression grinds the most servers to a halt.

So… is it relevant? The few parts that absolutely rely on secure data transport, can be coded by the user, the Java API makes that quite trivial, as sunsett just showed.

#49

I agree with Riven. It’s not practical on a high performance game server to really be doing true encryption, it just takes too much of the system resources away from what they should be doing. It’s probably a better idea to do some basic byte conversion negotiation up-front (similar to SSL) but much lighter and then communicate back and forth that way for the remainder of the communication.

However, I actually do intend to do heavier encryption for certain aspects of the game I’m developing. For example, if I want to provide the ability to pay with credit card in-game it will use strong encryption for that communication. Further, for many aspects of the MMO (like trading, buying, etc.) I will also use encryption. This is another benefit of JGN is that you can modularize the way your game is developed so you can have multiple communication paths for different needs.

#50

I know little about it, as it is a bit out of my scope of the work I do,

but what about dedicated (hardware/)chip?
tried google one of the first hits:
http://findarticles.com/p/articles/mi_zdpcm/is_200202/ai_ziff22528

surely this would give all kinds of issues. most likely you can’t address it directly with java, all the machines in your backbone would need one etc. Also if you limit the amount of data than it would limit the performance impact too. My point is that it’s perhaps unusual but not beyond exotic.

#51

How much searching did it take to find that? I live in that world and that’s the first I’ve seen of anything like that. You can find pretty much anything if you search for it on google, no matter how implausible it may be that anyone else in the world has it. :slight_smile:

I would say it is “exotic” at best. However, I’ll give you credit for an interesting idea and one that would actually work out pretty well if it were at all popular.

#52

I think I typed ssl hardware on google.

about the awareness of existence of hardware like that; euh at some convention unrelated to hardware (was about open source) years back before we where all hacking soho routers to run linux and vpn was crisp and new, there was some guy offering plain hardware like that(that beeing router-like hardware), which you could equip with your own software. It wasn’t that expensive so I listened for a while. He mentioned how you could like optionally stick a ssl card in there. Or other acceleration cards for niche/specific jobs.