Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Mar 2013
Offline Last Active Mar 23 2013 01:14 PM

Posts I've Made

In Topic: Need opinions on UDP and Local Routing

22 March 2013 - 09:18 AM

If you use player ids the cheating player can just add/sub a small value from his own id and then try to spoof it, but if he doesnt get to know the IP of other players, he cant spoof it easily?

Same goes for knowing the player ID of another player I would think. However, what you say is worth some thought. It would require doing a mapping from source ip/port (which is 6 bytes in ipv4) to the player stream handler. Certainly doable. And since the port is likely to change with each client creation of the source socket, it might work. Would have to make sure the client creates a single datagram handling outgoing socket and uses that rather than comming from a dozen ports. Interesting idea.


Its still spoofable of course, everything non-encrypted is. And whether I can stack on encryption depends on a ton of other issues.

In Topic: Need opinions on UDP and Local Routing

21 March 2013 - 11:22 PM

My concerns is that the single port will become innundated with tens of thousands of packets per second

Why do you think that the hash table that the OS is using to distribute different port traffic to different sockets would be any more efficient than your own hash table?

Why do you think that the number of ports would change how much buffering space is in the kernel, or how much capacity your network card have? There's only one network card, right? And if you had 10 socekts with 1 MB of buffer space each, why couldn't you have 1 socket with 10 MB of buffer space just as well?

It *may* be that those questions actually have answers that say you should use multiple sockets, but I would bet against it. Start with the simple solution. Complexificate things only when you *know* that you need to. There are many servers today that do hundreds of thousands of packets per second over a single socket with a single thread. (Although most of them I know of are using libevent and C/C++ rather than Java -- I don't know how much overhead Java adds.)

Also, are you trusting a player ID provided in a packet? If so, players may cheat. The best identification of players is by source IP+port, which you get when you call recvfrom() or similar functions.


I am not saying multiple sockets is the way to go. I was asking for opinions. It seems the tone of your reply is blasting me for that.


As for the final deployment, I will probably use a data center managed by a third party rather than do my own network configuration and in that situation I would assume there would be more than one network card on the rack.


As for the overhead Java adds, I dont know if its incredibly relevant. If the clock cycles that the compiled code adds is the highest worry of the app, I will have both a very powerful system and a very big smile on my face. I think the IO rates across the net will introduce far more overhead. And I am using Java because I can take advantage of some tools rather than reinventing the wheel. I can also precompile the byte code to native (rather than using JIT) if the need arises.


As for the player ID, I will point out that its not that hard to spoof a header in an IP package and make a packet seem like it is comming from anther source. If you can alter the player ID in the live stream, you can alter the IP & port. The question then becomes one of potentially using encryption of the data stream. Is there an encryption tech out there that is sufficiently fast as to not introduce unmanageble overhead but yet provide good enough protection of the stream? I believe there are some alternatives to choose from. But really that is a worry I will tackle later. A journey must be walked a step at a time, not leaped to the end.

In Topic: Need opinions on UDP and Local Routing

21 March 2013 - 02:44 PM

Oh I am aware of the other issues. :) But one issue at a time. Thanks for the feedback.