Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
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  
  What is the best way of creating packet?  (Read 3240 times)
0 Members and 1 Guest are viewing this topic.
Offline perfectlifepan

Senior Newbie




Java games rock!


« Posted 2005-04-12 06:00:50 »

  Hi,
  I am developing a multiplay online game with client/server model(HTTP) and client need to send a packet(with x,yz,....)to server every 40ms.However, the network efficiency seem to be slower when the packet is larger and larger.So, can anyone know how to make a good packet?(my packet format---- x&y&z&angle&hp&money)
Offline Matlu

Junior Member




Hasta La Victoria Siempre!


« Reply #1 - Posted 2005-04-12 10:14:42 »

Quote
  Hi,
  I am developing a multiplay online game with client/server model(HTTP) and client need to send a packet(with x,yz,....)to server every 40ms.However, the network efficiency seem to be slower when the packet is larger and larger.So, can anyone know how to make a good packet?(my packet format---- x&y&z&angle&hp&money)


1. Do you have any good reason to use http? The only one I can think of would be to avoid firewall problems, but most games just don't care about it.
2. messages sent every 40ms - that's 25 messages per second! Do you want to make first person shooter or what? I guess that games with such traffic should better use UDP... Anyway you should consider, if you need so many messages per second...

Multiplayer Online Games
http://www.duelboard.com
Offline Jeff

JGO Coder




Got any cats?


« Reply #2 - Posted 2005-04-17 07:12:40 »

My gut says that with HTPP you arent going to be able to process 25 packets a second, period.  Certainly not with an ysignificant number of players.

HTTP is a slow file-transfer protocl It was never designed for rapid streams of packets.

You need to either rethink your game and do something with much slower communciatio nneeds or,as  tohers have said, go lower then HTTPand use the TCP?Ip stack (either TCP, UDP or a combination of both.)

25 packets epr secodn is probably excessive in ANY case.   BY way of a reference DukeNukem3D when played over the internet spewed data at a rate of 7 packets a second.



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
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 #3 - Posted 2005-06-28 11:15:58 »

HTTP is a slow file-transfer protocl

Care to explain that?

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

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2005-06-28 11:50:38 »

It's got relatively verbose headers, often goes through more layers than necessary, and is really designed for sending big bits of data like pages and such around. You know that though.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #5 - Posted 2005-06-28 12:52:14 »

It's got relatively verbose headers, often goes through more layers than necessary, and is really designed for sending big bits of data like pages and such around. You know that though.

Cas Smiley

But it can be very efficient if you want it to be - plenty of games have been written with two-line headers (or less, one-line) and equally minimalist responses. Yes, you're flirting in the grey areas of the spec to do this, but all corret browsers and servers will accept this happily.

EDIT: and if you adopt HTTP/1.0, then this is actually fully correct anyway.

Although, to make the shitty Microsoft "we-cant-follow-a-spec-to-save-our-lives" InternetExplorer work properly, you have to add another hundred bytes or so (these bugs are present and noticeable even if you're being 100% legal about the protocol)

My point being that there's nothing wrong with HTTP as a game protocol per se, and it's an excellent "negotiated" protocol which is also highly efficient to parse - so long as you don't go overboard with putting tonnes of stuff in every request or response that actually doesn't need to be there and arguably shouldn't be. And, of course, there's always the huge benefits of being able to test using a web-browser Smiley

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2005-06-28 12:55:22 »


Just to be clear, given princec's post, why I'm asking is because AFAICS:

1. it's not a file-transfer protocol, it's a command protocol with a built-in content-transfer system and a protocol negotiation and content-negotiation system which can also transfer bulk data with arbitrary automatically handled encryption and compression - if desired - and which also optionally performs remote management of server-side resources

2. It's not slow

So ... interested to read more about what the OP was thinking of.

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

JGO Coder




Got any cats?


« Reply #7 - Posted 2005-06-29 08:13:27 »

Okay here' s what iw as thinking:

(1)  If you define HTTP as nothing more then the 80 port then sure you cna do anything over it BUT

(2) As designed HTTP was originally intended for transfer of text files.  It has a text header  and operator that is in itself verbose when you start looking at the size of game packets.  (A DukeNukem3D packet was a total of less then 20 bytes including the TCP over PDP and TEN headers of 8 bytes.) Games are VERY sensative to packet size, down to the byte, if you have any wish to support analog modems.

(3) HTTP at least as originally defined requires a TCP connection be made for each exchnage.  TCP connecting is very slow.

(4) Text parsing of any kind is very slow compared to binary data handling.

Its an ill fit for the needs of serious games.



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 blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2005-06-29 10:48:55 »

(2) As designed HTTP was originally intended for transfer of text files.  It has a text header  and operator that is in itself verbose when you start looking at the size of game packets.  (A DukeNukem3D packet was a total of less then 20 bytes including the TCP over PDP and TEN headers of 8 bytes.) Games are VERY sensative to packet size, down to the byte, if you have any wish to support analog modems.

OK, so you were basically talking about byte-count overheads, got ya.

Quote
(3) HTTP at least as originally defined requires a TCP connection be made for each exchnage.  TCP connecting is very slow.

...but no-one actually does that these days.

Quote
(4) Text parsing of any kind is very slow compared to binary data handling.

...and that's misleading: in HTTP's case it's specifically engineered so that you can do the processing as bytes rather than text. There's only one change that would make HTTP more efficient to parse than it already is, and that's if the CRLF terminator were replaced with a prefix length string, which would be nice, and ditio for the double-CRLF.

The improvement would be small, I suspect barely noticeable except in extreme cases, but certainly it would be an improvement.

Quote
Its an ill fit for the needs of serious games.

But, as has been pointed out many times, games should generally be aiming for relatively large packets anyway, no (because of the fairly large per-packet overheads, and the automatic inline compression that often occurs in links)? In which case, the above statement rings false, and we come back to why I was surprised to see you put HTTP down as being particuarly bad for games.

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

JGO Coder




Got any cats?


« Reply #9 - Posted 2005-06-30 09:11:03 »

Quote
(3) HTTP at least as originally defined requires a TCP connection be made for each exchnage.  TCP connecting is very slow.

...but no-one actually does that these days.

They dont?  Firefox sure seems to every time I fetch a page...

Quote
Quote
(4) Text parsing of any kind is very slow compared to binary data handling.

...and that's misleading: in HTTP's case it's specifically engineered so that you can do the processing as bytes rather than text.
An interesting comment and one Ive never ehard before.  All the servlet examples Ive ever seen do text parsing and text assembly.  There may be better techniques but they are new to me. have a good reference?



Quote
But, as has been pointed out many times, games should generally be aiming for relatively large packets anyway, no (because of the fairly large per-packet overheads, and the automatic inline compression that often occurs in links)?

Dont follow you at all. What links and what comrpession are you referring to?

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #10 - Posted 2005-06-30 09:32:59 »

Wait, I'm confused.

Blahblahblah: Are you saying that http is the best choice for in-game communications with 25 packages per second? :-/

Play Minecraft!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2005-06-30 10:15:38 »

Wait, I'm confused.

Blahblahblah: Are you saying that http is the best choice for in-game communications with 25 packages per second? :-/

No, sorry if it sounded that way.

I was, however, tryign to say that HTTP is a very good protocol for generic communication, and often a good choice for games - that it should certainly not be dismissed on the grounds of speed (it's fast, if you write decent code - but of course no point in premature optimization!), and that to think of it as a file-transfer protocol is to ignore perhaps 75% of what it is actually about Sad.

You think 25 Hz per player is a lot of traffic? Well, out of the box, apache will do 2000 request + responses per second. Out of the box, tomcat will do 300-400 fully dynamic requests a second. 25 Hz per player isn't going to make an HTTP server break sweat.

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2005-06-30 10:23:13 »

LOL, jeff you're trolling like a madman. You nearly got me, but when you get as far as not knowing what the term "link" means in networking, and expressing surprise at the compression that you yoursefl posted about in this forum it penetrated my thick skull and I realised what was going on Smiley.

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

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #13 - Posted 2005-06-30 10:59:21 »

I really should stop replying to your nonsense, but:

I was, however, tryign to say that HTTP is a very good protocol for generic communication, and often a good choice for games - that it should certainly not be dismissed on the grounds of speed (it's fast, if you write decent code - but of course no point in premature optimization!), and that to think of it as a file-transfer protocol is to ignore perhaps 75% of what it is actually about Sad.

It's not fast compared to other alternatives, no matter how you look at it. The only thing slower than http might be sending emails, or possibly shouting.

You think 25 Hz per player is a lot of traffic? Well, out of the box, apache will do 2000 request + responses per second. Out of the box, tomcat will do 300-400 fully dynamic requests a second. 25 Hz per player isn't going to make an HTTP server break sweat.

25 hz per player is insanely much traffic, yes, especially if you use HTTP.
In fact, if you don't do fancy threading to have several calls going at once, it's impossible to reach 25hz per player unless the roundtrip time ("ping") is less than 40 ms.

Just admit http is a horrible choice for games with a lot of traffic, and we can move on.

Play Minecraft!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2005-07-14 17:16:43 »

Context, my dear fellow, context: don't reply and take comments out of their context.

It's not fast compared to other alternatives, no matter how you look at it. The only thing slower than http might be sending emails, or possibly shouting.

It's fast to parse. It is also (if you want it to be) as fast to send info in as any text protocol. Indeed, I've seen people use HTTP as a pure binary protocol with heavy compression. Works fine - you send one request with indefinite length (or very long) and just keep streaming data in. It's not really in the spirit of the protocol, but it works. Shrug.

Quote
Just admit http is a horrible choice for games with a lot of traffic, and we can move on.

That's not really what I was contesting. I contested that it was a bad protocol for games development. IMHO it's a good protocol for games. To quote myself:

   "My point being that there's nothing wrong with HTTP as a game protocol per se"

   "...often a good choice for games - that it should certainly not be dismissed on the grounds of speed"

...and we shouldn't just dismiss it as "slow file-transfer" and move on, because that's plain wrong. By all means, dismiss it because you want to transfer 3 bytes 50 times a second, but not out of hand for high-level inaccurate sweeping statements about speed and efficiency.

And, as jeff said:
25 packets epr secodn is probably excessive in ANY case.

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.

pw (37 views)
2014-07-24 01:59:36

Riven (38 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!