Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
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  
  sending location data  (Read 2587 times)
0 Members and 1 Guest are viewing this topic.
Offline MickeyB

Senior Member




my game will work, my game will work!


« Posted 2004-02-09 21:33:11 »

Without sounding too much like a noob...

Using tcp, what is the best socket setup for sending int locations (x and y)  where x could be -10000 to 10000 and so can y.

ie. BufferedReader, DataReader, etc...?



MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #1 - Posted 2004-02-10 05:05:26 »

Hi
 For old style IO (java.io and java.net classes) I use DataInputStream and DataOutputStream. Very handy as you don't have to worry about little/big endian issues etc, or codesets with strings etc, writeFloat, writeUTF, etc etc, v simple to use.

HTH

Endolf

Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #2 - Posted 2004-02-11 17:05:40 »

Is there a way to create generic packets while mixing data types through the DataInputStream?

how are you guys doing it?  I need to send a command id(can be a byte or int) then based on that command id, I may need to send 3 ints, and 2 floats, or 10 ints, or 5 ints and 5 stings, etc...

Are you guys building a large switch and predefining what you know you will be sending in your client?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2004-02-11 20:42:00 »

Yup, thats what I do.  One of the few vaild uses I know of in Java for a switch{} clause, unwrapping packets.

If you are going to get complex with multiple layers of protocol, and its really a bottleneck, you *might* want to look at NIO because it has copy-less ways of doign such wrapping.

Until you know its a bottleneck though I wouldnt worry about it.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline tom
« Reply #4 - Posted 2004-02-11 20:59:44 »

Quote
Are you guys building a large switch and predefining what you know you will be sending in your client?


This is how I do it. All packets starts with a packet type that is read first. Then there is a switch, and each type is handled seperately. Code looks something like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
DataInput dataIn = aDataInputStreamWrappedAroundSocketStream;
int msgType = dataIn.readByte();
switch (msgType) {
case MSG_POSITION:
   int playerId = dataIn.readInt();
   float x = dataIn.readFloat();
   float y = dataIn.readFloat();
   myGame.positionUpdate(playerId, x, y);
   break;
case MSG_BULLET:
   int ownerId = dataIn.readInt();
   float bulletStartx = dataIn.readFloat();
   float bulletStarty = dataIn.readFloat();
   float bulletAngle = dataIn.readFloat();
   myGame.bulletSpawned(ownerId, bulletStartx, bulletStarty, bulletAngle);
   break;
... // the reset of the packet types goes here
default:
   System.out.println("Warning! packet type not supported "+msgType);
}


The sender has to create the packets so that it matches the reader. It would use a DataOutputStream to write the data using the coresponding calls writeFloat/readFloat, writeUTF/readUTF etc.

Offline kevglass

JGO Kernel


Medals: 171
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2004-02-12 04:50:35 »

It might be more pretty to wrap up the encoding/decoding into a Message object and spawn one of these based on a Class[] array indexed on message.

More pretty, easier to maintain, but as normal, slightly slower.

Kev

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #6 - Posted 2004-02-12 05:08:00 »

I use to define a 'Identity' interface, which subclasses (NamedIdentity, ByteIdentity, ShortIdentity, LongIdentity) are used to identify anything in my system.

The 'message type' is represented by such an Identity. Identities can be decoded from messages with a certain protocol and each message is lead by a identity definition.

There is a HashMap that maps identities to message handlers. On an incoming message, the identity is decoded, looked up in the HashMap and the corresponding set of handlers in notified.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
      Identity      TICKET_ID = new NamedIdentity( "TESTTICKETID" );


      ReportingBusListener listener = new ReportingBusListener( false );

      mClient.add( TICKET_ID, listener );

      BusTicket t = new BusTicket( TICKET_ID );
      t.putInt( 87654321 );
      t.putDouble( Math.PI );
     
      mBusLine.enter( t );            
      mBusLine.sendBus();



Technically, my message class ('BusTicket') extends a ByteBuffer adding methods like getIdentity() and putIdentity(). BusTickets are transfered via NIO of course.

You can look it up - if you like - in the HeadQuarters packages 'de.hardcode.hq.identity' and 'de.hardcode.hq.objectbus' on

 http://www.sourceforge.net/drts

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #7 - Posted 2004-02-12 10:57:07 »

as usual you guys rock.  I used the switch scenarios for a couple of my earlier games, but started thinking further out into complexity when I should have stuck with the "if it ain't broke, dont fix it....if it is broke, duct it"

Thnaks again!

M

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2004-02-12 11:42:19 »

(how come Cas hasn't popped up to promote struts yet? Wink)

I tend to favour mixing some indirection in - like kevglass's suggestion - and typically do e.g.

MSG := id type [ payload ] delimiter
ID := (e.g. a four-digit semi-unique ID that is VERY useful in client and server debugging)
TYPE := (e.g. a four-digit message-type specifier)
DELIMETER := (e.g. some special char so that I can parse out individual messages without needing to know the length or the format of the payload)
PAYLOAD := (could be anything not containing the delimiter)

If you're suspicious / worried about broken message readers/writers, you can put a compulsory delimiter before the ID too - this means that if an encoder omits the "end-of-message" you can still recover.

I typically use TYPE as a key into a table of things to parse out the message. This helps with versioning too - you can effortlessly run a server/client that speaks simultaneous versions of the packet formats by just defining a new TYPE for each successive version of each different message.

Disclaimer: I don't do any work on packet-optimization, and my normal concern is only "can I debug this easily? can I upgrade it easily?" so long as I know I can easily replace the entire protocol with someone else's optimized protocol.

malloc will be first against the wall when the revolution comes...
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #9 - Posted 2004-02-12 13:23:01 »

your PAYLOAD does NOT contain the delimieter?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2004-02-12 14:10:47 »

Quote
your PAYLOAD does NOT contain the delimieter?


Why would you want to do anything different Huh The low-level, non-message-type-specific code couldn't care less what's in the payload - it just needs to know where it starts and ends, and my definition lets you do (in pseudo-code):

1  
2  
3  
4  
while( not yet found delimiter )
{
  buffer.add( getByte( input ) );
}

malloc will be first against the wall when the revolution comes...
Offline tom
« Reply #11 - Posted 2004-02-12 14:54:46 »

Unless I missed something, you also have to deal with the fact that the delimiter can be in the payload. In wich case you have to replace the delimiter with some escape characters.

But I see no need to use a delimiter in my code. I know the length of the payload before I send it.

Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #12 - Posted 2004-02-12 15:45:24 »

an example of payload contents would be: ...

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2004-02-12 16:07:03 »

Quote
Unless I missed something, you also have to deal with the fact that the delimiter can be in the payload. In wich case you have to replace the delimiter with some escape characters.


c.f. my post, I prefer to make the delimeter something that won't be used in the payload. Where that's not possible, obviously yes the sender / encoder has to do a search/replace to remove it. Often the only big problem comes when you have to insert binary data which you didn't generate (e.g. a file).

Quote

But I see no need to use a delimiter in my code. I know the length of the payload before I send it.


Shrug; my post was about how *I* prefer to do it - and I have to deal with variable length payloads most of the time.

Delimeters also help *massively* when debugging protocol-level problems. This is the voice of bitter experience - always include an explicit delimeter and an explicit semi-unique messageid in any network protocol. Unless you have a trivial protocol or will never upgrade it, and never accept other people's codecs for it (which is easy enough in a lot of simple cases).

Also comes from my experience of writing the odd binary-stream debugging tool, including self-healing ones (which can be very very helpful when working with a non-standard reliable / in-order protocol, where there may be bugs in the implementation - NB: e.g. the TCP/IP implementation on an esoteric platform may not be all that perfect!).

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 171
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #14 - Posted 2004-02-12 16:58:00 »

I normally don't go in for all this delimeter stuff Wink

I go for something like this:

<MSG CODE><MSG LENGTH><PAYLOAD>

Based on the message code I construct a message object which complies to a lovely interface normally called Message. The right amount of data is read of the stream based on the msg length. This block of data is passed into the message object wrapped up in a ByteArrayInputStream and then a DataInputStream.

Then for each type of message, UpdateLocation, AddEntity, RemoveEntity I implement an object which can decode the payload (and actually encode it on the way out).

It seems like a lot of overhead, but its awful perty.. Smiley

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2004-02-12 17:17:39 »

Quote

I go for something like this:


Same here, but I have to trust 3rd party message implementations - e.g. providing a pluggable protocol - and if they screw up (e.g. have often seen cases where message length is calcualted wrong, especially when they counted in chars but encoded in 16-bit UTF etc, or when they did a dodgy divide and were out-by-one) then it damages all future messages on that wire.

The message id is ABSOLUTELY ESSENTIAL for the first time you have a problem between client and server where you need to match up what one was doing compared to the other. Especially useful if you ever "lose" a message, or have race condition problems (forgot to synchronize somewhere, or synchronized in the wrong place / on the wrong object). Have seen this lots of times before...

With a message id, you can just open the logfiles for client and server side-by-side and quickly track down the problem.

malloc will be first against the wall when the revolution comes...
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #16 - Posted 2004-02-13 07:26:29 »

Quote

Often the only big problem comes when you have to insert binary data which you didn't generate (e.g. a file).


But binary data is the usual case, isn't it?

I run the <HEADER><LENGTH><DATA> approach as well. And ONLY binary data of cource. But I don't rely on anyone to calculate the length for me. They hand in a ByteBuffer like thingy and I pack it into a message.

But yes, if anything goes wrong, it is rather hard to recover. Typically I close the line then Sad

OTOH, after setting up (and debugging) the basic protocol properly (and having a good TCP implementation underneath), I did not encounter too many problems with that any more.

Adding a message ID, maybe optionally, sounds like a thing to consider, because the high-level protocol interactions can be really ugly and a ID helps to do meaningful logging.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline kevglass

JGO Kernel


Medals: 171
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #17 - Posted 2004-02-13 08:55:03 »

On my side I caculate the message length like Herk mentioned, counting what they populated into the byte buffer, but I can understand the problem when you design a pure protocol and have to support other folks design their own APIs around it (even in different languages).

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2004-02-13 10:04:06 »

Quote
I can understand the problem when you design a pure protocol and have to support other folks design their own APIs around it (even in different languages).

Kev


Exactly. Kev's and Herk's comments are good advice for  dealing with local "untrustworthy" encoders, but when I said I didn't trust the encoders, I was also referring to what's the other side of the socket. Remember that you have NO CONTROL over encoders the other side of the socket - in general you can't even guarantee that the remote machine is running your code. (or, as Kev pointed out, that it's even running code written in the same language!).

NB: I have seen several cases where people have reverse-engineered someone's protocol, badly, and their attempts to speak with the server / other clients have just crashed everything around them, because the designers of the network protocol weren't farsighted enough to realise how easy it would be for someone to attempt this. Not even thinking about deliberate DoS attempts, there are lots of people who like to play with things...

It's a bit like IP, DNS, etc. The designers never really thought of the possibility that someone else might break the protocols accidentally, let alone deliberately, and didn't put any safeguards in the design (although they did guard against hardware failure at all points, which is ironic given that today the network hardware is pretty rock solid, but badly-implemented IP stacks etc have caused no end of problems Smiley).

Final thought: I'm pretty sure the majority of webserver crashes (discounting massive overload - DoS attacks etc) are due to malformed HTTP requests. The last webserver I put on the net had it's first malformed request within a couple of days (!), and this was a server not linked to from anywhere - they just found it by IP scanning. These days, for net-connected servers running our MMOG tech, we tend to see dozens of bad-request attacks every day (occasionally we scan the logs for anything interesting happening like this). This is even with auto responders which generate webpages saying "We know what you're doing, don't bother. We've logged your IP Address" (nb: that does cut down the attacks a little; I guess scanners these days show the hacker the output from the server? [although I'd be interested to hear from anyone who has used / seen a modern scanner...it's been several years since I looked].

PS, FYI the last time I looked at the ISP's of crackers in one week of requests, they were pretty much evenly distributed amongst South America, India, China, Eastern Europe and Canada. On the whole, we don't tend to get hit twice by the same person (perhaps their scanners automatically black list us when the attack fails miserably? Perhaps their ISP's terminate them when the detect the scanning?).

malloc will be first against the wall when the revolution comes...
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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (44 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (62 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (39 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
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!