Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Networking techniques  (Read 1663 times)
0 Members and 1 Guest are viewing this topic.
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Posted 2010-10-21 18:39:30 »

Howdy.

I do not make anything that is networked.. ever. I want to change that but when I do networking my packets are just strings with a syntax.
When I see other peoples protocols however, it seems they are sending different bytes - which would obviously be a lot faster, and lighter if that is in fact how it works.

Now to my question:
Is there any articles/books (anything!) that tells about this topic for Java applications? I really want to learn about this, but I want to make sure I do not read something outdated, or something bad.  Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 784
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2010-10-21 18:44:51 »

If you want to get something done, keep it simple.

If strings do the job for you, and you don't run into trouble, stay with strings. Binary network APIs can be a huge time saver or a massive time sink.

Especially if you are just starting out, doing networking with strings is just fine. You should get a feel of the problems to solve, which will come in handy when you start using network APIs later.

A poor example maybe, but you (should) start Java programming with command-line apps, to get a feel for the language, not dive into Swing for the first few months.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #2 - Posted 2010-10-21 19:21:11 »

If you want to get something done, keep it simple.

If strings do the job for you, and you don't run into trouble, stay with strings. Binary network APIs can be a huge time saver or a massive time sink.

Especially if you are just starting out, doing networking with strings is just fine. You should get a feel of the problems to solve, which will come in handy when you start using network APIs later.

A poor example maybe, but you (should) start Java programming with command-line apps, to get a feel for the language, not dive into Swing for the first few months.

Thanks for your response!  Cheesy
I have made some things (not a lot though..) that uses strings in packets, but I really want to learn to use both.

About the last statement: I almost only create command-line applications  Cheesy It's only for my own eyes, and working with swing is so... unpleasing  Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #3 - Posted 2010-10-28 17:13:33 »

I've been using ObjectOutputStream. I made an Interface called GameMessage which has methods for various calls any message might need, like isHeartbeat() (a heartbeat message is not sent to client, but keeps the server from disconnecting the client) isEchoed() (an echoed message is immediately sent back to every client as long as it's valid, useful for chatrooms etc.) isDisconnect() (sent from a client when they've disconnected) etc. Then I make any sort of class and as long as it's Serializable and implements GameMessage it can be sent around no problem.

If you're using bytes, the process is pretty much the same as sending objects or strings, you just need some way of determining what's being sent and sending it in a reasonable way. Typically you have a certain byte value that indicates the start of a new message and/or have one to indicate the end of a message. As you receive bytes, you buffer them into a byte array, then when you've got a complete message you interpret what it is from your bytes. Complication here arises from needing to restrict data bytes from equaling the start/end byte values. If they do, you're borked. To remedy this, You can also just assume that every message is X bytes long, read in that many bytes, then figure out what it means. In this case, however, you might as well just send an object or a string (in my opinion) because you're wasting enough bytes that you're losing the advantage of the byte stream.

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 784
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2010-10-28 18:08:13 »

If you use Serialization, how are you going to stop me from hijacking all your heap memory by sending a bogus byte-array size?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #5 - Posted 2010-10-28 18:29:25 »

Typically you have a certain byte value that indicates the start of a new message and/or have one to indicate the end of a message. As you receive bytes, you buffer them into a byte array, then when you've got a complete message you interpret what it is from your bytes. Complication here arises from needing to restrict data bytes from equaling the start/end byte values. If they do, you're borked. To remedy this, You can also just assume that every message is X bytes long, read in that many bytes, then figure out what it means. In this case, however, you might as well just send an object or a string (in my opinion) because you're wasting enough bytes that you're losing the advantage of the byte stream.

Ignoring that java.util.Serialization sucks... You definitely want to go with writing a length. This in no way wastes enough bytes that it warrants just sending strings. Sending a length takes only 1 byte for small messages and 2 bytes for nearly any other messages.

That said, it usually doesn't matter what you are sending over the wire. Abstract that away so you send an object and get an object on the other side. Then you can switch out your serialization without affecting your app. Step #1: get something working.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2010-10-28 21:40:24 »

If you use Serialization, how are you going to stop me from hijacking all your heap memory by sending a bogus byte-array size?
I have no idea.  Smiley

The way I set my server up for the moment though that'll just lock up your own client thread and still leave the server capable of handling everything else while it tries to pull in your junk. But I guess it would indeed eventually break the heap. Is there any way around this, or should I just stick with fixed byte sizes?

See my work:
OTC Software
Offline ryanm

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #7 - Posted 2010-10-28 21:59:29 »

It's the same old security refrain: don't trust the client. Have some sanity checks on incoming data size, I would guess.
Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #8 - Posted 2010-10-29 14:35:21 »

Another option is 3rd party serialization libraries like Google P Buffers.  This is what I considered using last time I did networking.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #9 - Posted 2010-10-29 14:53:29 »

It's the same old security refrain: don't trust the client. Have some sanity checks on incoming data size, I would guess.
Yeah but since I'm using ObjectInputStream there is no way of just cutting off the stream halfway through. It will start reading the next object and won't stop until it's totally read.

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #10 - Posted 2010-10-29 22:41:49 »

Yeah but since I'm using ObjectInputStream there is no way of just cutting off the stream halfway through. It will start reading the next object and won't stop until it's totally read.

Read length, close connection if length is too large, receive TCP data until we have that many bytes, present bytes to java.util.Serialization, close connection if serialization fails.

Another option is 3rd party serialization libraries like Google P Buffers.  This is what I considered using last time I did networking.

This! Or, somewhat more specifically, this! Smiley

Offline pjt33
« Reply #11 - Posted 2010-10-29 23:16:07 »

Now to my question:
Is there any articles/books (anything!) that tells about this topic for Java applications? I really want to learn about this, but I want to make sure I do not read something outdated, or something bad.  Smiley
I don't know any, but allow me to share what I've learnt the hard way. (Not always through my own errors - I've had plenty of pain fixing broken protocols written by other people too). These rules apply equally to network protocols and file formats (for level data, save files, etc).

1. Always have a header which includes a version number. Even for version 0.0.1. Otherwise when you make a breaking change to the protocol/format you will have major problems.
2. If a field is of variable length, either encode the length and write that first (my preferred option) or ensure that they are self-limiting. For strings this means that you have a delimiter character and an escaping mechanism. For integers which are usually small, study UTF-8's approach.

There's more to good network protocol design than this, but getting these basics wrong will hurt you.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (16 views)
2014-08-31 22:59:12

TehJavaDev (24 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (73 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!