Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5
  ignore  |  Print  
  UDP Vs TCP/IP  (Read 91827 times)
0 Members and 1 Guest are viewing this topic.
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #90 - Posted 2003-11-19 16:37:51 »

Hi
 This is actaully the whole point, why bother?, if your gonna write TCP, why not jsut use it? If on the other hand you really want datagrams that are unreliable, then use UDP, but there is no point to rewritting TCP on UDP unless it's for pure research.

Endolf

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #91 - Posted 2003-11-19 17:02:55 »

Quote

There seem to be some errors way back.

For instance.. blahblahblah wrote that TCP packets can be much bigger than UDP packets and therefore TCP was just as fast or faster.


I'll have a look again asap (and edit this post - but I've no access at the moment and am on slow mobile dialup), but FWIW IIRC I was making the point that in practice TCP packets could be sent with larger payloads, precisely because TCP would efficiently manage fragmentation for you - whereas UDP packets would just die if you sent them too large.

IIRC I was talking about the way in which you use the protocol (take advantage of TCP features) rather than mere theoretical abilities of either - given that TCP can be implemented pretty well in UDP, at some point you of course have to look at the practicalities of each.

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

Senior Member




Friendly fire isn't friendly!


« Reply #92 - Posted 2003-11-19 17:08:29 »

Quote
I have recently written my own MMOG network layer (to support 1000+ clients on a couple of ports) using the TCP SACK system outlined in 'RFC 3517'


Grin If you implement TCP, you'll get TCP ....

What are the advantages of your impl over TCP? Maybe you are willing to share?

TCP in fact is not based on UDP but on IP - so I assume this can turn out as an advantage over every other approach based on UDP.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
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 #93 - Posted 2003-11-19 17:11:19 »

Quote
No. TCP or UDP still is application specific. And UDP is the better choice to setup own, task specific protocols (like Quake or NFS e.g.).


i.e. UDP is always going to be useful as the "empty pizza base" on which to write whatever protocol you want? Libraries exist in all languages for dealing with UDP packets, and it's usually easier to code to those than to talk directly to your network hardware etc.

E.g. in java it's not possible to hand-craft packets except by using UDP.

PS TCP is not inefficient, it just has extra features that many games developers don't use and don't want. If it had two flags "disableInOrderDelivery" and "disableGuaranteedDelivery" it would probably be used for all game protocols Wink - most people enjoy the other features of TCP that UDP lacks.

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

Junior Member




... Boing ...


« Reply #94 - Posted 2003-11-19 17:12:14 »

I did it mainly because Im planning for 1000+ connections. For this:

1) Header size too large
2) Socket per connection is too expensive
3) Congestion measurements can be differentiated between 'client link' congestion, and 'server side' congestion. This allows us to throttle either the whole server, or just specific clients which is impossible to do with 1000 seperate sockets. Each one just performs congestion avoidance on its own link.
4) Network layer level encryption and security is better implemented at the lowest level.

For a simple 8-16 player peer-to-peer session then TCP is perfectly satisfactory. But it does not fit every case. Although i would agree that the range of cases it does work fine for is generally a lot larger than people give it credit for.

- Dom
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #95 - Posted 2003-11-19 17:25:35 »

Quote
PS TCP is not inefficient, it just has extra features that many games developers don't use and don't want. If it had two flags "disableInOrderDelivery" and "disableGuaranteedDelivery" it would probably be used for all game protocols Wink - most people enjoy the other features of TCP that UDP lacks.


By jove!, i think he's cracked it!. This probably sums up most of the past 90 odd posts Smiley

Endolf.

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #96 - Posted 2003-11-19 17:47:44 »

Quote
I did it mainly because Im planning for 1000+ connections.


1000 connections - damn good argument against TCP sockets.

Putting TCP-things over UDP - how much code is that? Just to give me an idea?

BTW, how do stateless app servers handle 1000 or more clients? Do they use TCP and create connections for each server access?

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

Junior Member




... Boing ...


« Reply #97 - Posted 2003-11-19 18:00:20 »

Its around 2000 lines of code (all in C++ at the mo), half of that is mainly buffer management to remove any dynamic allocations for the game server (decryption of a valid packet is placed in a reference counted buffer that is tagged to a linked list of packets for each client, when done its added to a linked list of free buffers).  The actual TCP you could probably do in around 2-300 lines.

Not sure what you mean by a stateless server, if its like a web server then they create & destroy the connections each time I think.

- Dom
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #98 - Posted 2003-11-19 20:08:49 »

Quote
The actual TCP you could probably do in around 2-300 lines.


2 lines really is very few code  Grin

Quote

Not sure what you mean by a stateless server, if its like a web server then they create & destroy the connections each time I think.


An appserver dealing with stateless beans. Do stateful beans keep connections open?

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

Senior Member


Medals: 1


Who, me?


« Reply #99 - Posted 2003-11-19 22:18:48 »

Quote
An appserver dealing with stateless beans. Do stateful beans keep connections open?


Are you talking client-server J2EE here?

Stateful or stateless, a J2EE server will (usually) still be using HTTP to communicate.  So the connection is made and broken for each interaction, apart from using Keep-Alives for referenced resources.

Hellomynameis Charlie Dobbie.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #100 - Posted 2003-11-20 02:31:08 »

Quote

Not True for serial PPP.

I said not counting that!  I'm thinking broadband at the moment.


Quote
Not True.  The sender doesn't wait for ACKs.  Its a NAK based protocol (at least in all modern implementations.) The sender just keeps pumping packets but keeps a "sliding window" of history of past packets.  When it gets a NAK on an old packet, it retransmits from that history.


I admit that I haven't done the math, but I have read the papers of those that did.  I believe my statement is true.
It CAN'T be NAK based with a sliding window.  It is IMPOSSIBLE to be reliable that way.  Think about it.  No NAK is received to request re-transmission of the oldest packet in the window.  A new packet is transmitted and so the window advances overwriting that old packet in the sliding window buffer.  NOW a NAK is received for that old packet.... oops too late, it is out of the buffer and not available to retransmit.
I believe it is ACK based with a sliding window.. and that is where the round trip time comes in to play.. transmission MUST either be suspended if the oldest packet is not yet ACKed, or that old packet must be re-transmitted automatically.  Either way no new data is sent in that situation until the ACK is received.  The time for the ACKs to get back and the size of the sliding window establish an upper limit on the transmission rate regardless of the speed of the channel.


Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #101 - Posted 2003-11-20 08:28:15 »

Quote
I believe it is ACK based with a sliding window.. and that is where the round trip time comes in to play.. transmission MUST either be suspended if the oldest packet is not yet ACKed, or that old packet must be re-transmitted automatically.  Either way no new data is sent in that situation until the ACK is received.  The time for the ACKs to get back and the size of the sliding window establish an upper limit on the transmission rate regardless of the speed of the channel.

But this all depends on the size on your window.  As you have to block when the oldest packet isn't acknowledged, you can just make your buffer bigger and increase your retry rate.

E.g., just to give an example, have a sliding window of x seconds, retransmit anything requested immediately, or anythinng not acknowledged every x/y seconds.  This gives y chances for each packet to get through, and you'll only block if none of them get through.

Hellomynameis Charlie Dobbie.
Offline Jeff

JGO Coder




Got any cats?


« Reply #102 - Posted 2003-11-20 20:50:49 »

Quote
It CAN'T be NAK based with a sliding window.  It is IMPOSSIBLE to be reliable that way.  Think about it.  No NAK is received to request re-transmission of the oldest packet in the window.  A new packet is transmitted and so the window advances overwriting that old packet in the sliding window buffer.  NOW a NAK is received for that old packet.... oops too late,


This is assuming you want to reliably COMPLETE transmission under all cases.  Clearly there are already cases  on the internet where that isn't true (ie  a main router goes down in the middle of the transmission.)

In  practice all you need is a window large enough to cover some "maximum wait time" beyond which you would simply abort the transmission as "failed."  As long as this maximum is larger then 99.99%  of the internet lags experienced, you have "4-nines" of reliability, which is damn good.

Absolute anythings aren't usually efficient.  Cut off the one ina million end cases and things improve a lot Smiley  I'm not saying this IS how its done, but it is certainly POSSIBLE to do it this way.

The way to find out for sure what's going on is to go to the MAGIC archive and search the RFEs.  If i had time, Id do that, but I don't right now.

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 swpalmer

JGO Coder




Where's the Kaboom?


« Reply #103 - Posted 2003-11-21 02:24:20 »

Your NAK method depends on reliable delivery of NAKs..  and it would be sensitive to lags in the response time.. a fast sender could overrun the sliding window before the first NAK came back.

I have been reading a very good TCP/IP book, I don't have it with me now.. But I'm pretty sure TCP is ACK based with the sliding window.

I know you can simply unplug the network cable and it wouldn't matter how "reliable" TCP is - your data isn't going to get through.  I was refering to the effect on throughput, not reliability. I think timeouts are set such that you will see a significant slowdown well before you see failures.

Yes the size of the window can improve performance and it can grow dynamically etc..  But my point was that RTT (Round Trip Time) combined with the (max or current) size of the sliding window determines a maximum throughput that is independent of the transport speed.  I am pretty sure that is true.

That's why using Forward Error Correction and UDP you can eliminate the need for a sliding window and dramatically improve throughput IF you have high RTT (ping) or a lossy connection.  I'm not suggesting this is particularly useful information for games though... perhaps it would be useful for server downloads like models, levels, updates, etc.

My main point was that reliability can in many cases not matter, so doing without it might give you a measurable gain.  Specially if clients can connect to a multicast group to get the game state.  Though I don't know enough about multicast yet to know how practical that is. It seems to make sense.

Take the networked Power Pong game mentioned in another forum.  The state of the game is so tiny, and the ball is basically always moving...  so there needs to be relatively constant network traffic anyway.. so just have the server constantly, at some fixed rate, tuned for the speed of the channel, send the current state of the game with a timestamp.  The client could send the paddle moves with TCP only when the paddle position changes, or it can do something like the server and simply send the current paddle position constantly (with timestamps) at a fixed rate.

Offline Jeff

JGO Coder




Got any cats?


« Reply #104 - Posted 2003-11-25 01:06:25 »

Hmm.

I guess Ill go to MAGIC and look, but NAK based re-transmission dates all the way back to Zmodem.  I'd be surpised if TCP sat and waited for individual ACKs.  (In fact Im sure it doesn't, though a large sliding buffer of packets awaiting ACKs I suppose is possible.)

On your PowerPong, unless im missing something in the game design I wouldnt flood the world with UDP packets.  All the motion is predictable given the collision point of ball and paddle.  I haven't sat down and worked it out but I my instincts say one reliable packet per collision would work fine.  You have all the time of the travel of the ball to synch up.  (And if you are clever and slightly time delay one players' view of the other players' actions you can easily cover the critical timing at that point.)

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 Jeff

JGO Coder




Got any cats?


« Reply #105 - Posted 2003-11-25 04:25:52 »

So i've started researching.  The initial answer seems to be it isn't simple ACK or NAK, but a pretty evolved and complex hybrid.

This is my first reference, it references others....

http://www.faqs.org/rfcs/rfc1106.html

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 swpalmer

JGO Coder




Where's the Kaboom?


« Reply #106 - Posted 2003-11-25 11:44:48 »

Yes, the pong example was over simplified.  But it makes the point.. assume the client can't predict very far into the future and so client prediction is only useful for smoothing out the action.


The reference you linked to states:
Quote
This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.


It *is* old (1989) - but is it in widespread use?  My reference (TCP/IP Illustrated Vol.1-3) is newer.

The first paragraph of the introduction also backs up my point about RTT and loss limiting the throughput.
Quote
After the last batch of algorithm improvements to TCP, performance over high bandwidth*delay networks is still very poor.


For the record, my company has just licensed a UDP-based transporter that uses FEC and in real world tests we are seeing significant gains over TCP (50% + just from Texas to Toronto where there is almost 0 packet loss and ping <=100ms).  We need to move large video files from one side of the world to another.  The speed ups can be VERY substantial (500%) with even a little bit of packet loss.

*edit*  I'm comparing to regular FTP - which is not the fastest TCP based transfer protocol.

Also note Figure 1 in the Appendix - see the massive drop in throughput caused by an error rate of 10e-7.  It is better using this proposed protocol, but error rate of 10e-6 still severely cripples the throughput.  Actual loss on the Internet from for example Singapore to L.A. can easily be 10e-6.

Offline Jeff

JGO Coder




Got any cats?


« Reply #107 - Posted 2003-11-25 22:19:19 »

I *think* your video protocol gets us back to initial contentions.

(A) if you don't need reliable or in order devliery then by all means use UDP (unless you have serial PPP bandwidth issues.)  Thats what its for!

(B) For very domain specific things, WHERE you are really willing to do the not unsubstantial work of developing a sophisticated protocol, I absolutely agree you can improve on TCP.  As i mentioned we had a hybrid TCP/UDP protocol Bill developed at TEN for very specific types of games (Quake2 like) that was a big improvement over pure TCP or simple UDP.

But its a lot of work and requires a pretty deep understanding of how the net actually functions.  People who just slap a simple reliability/ordering protocol on top of UDP are reinventing the wheel and end up only hurting their performance.

Unfortunately, that last is the most common occurance in games that decide to "use UDP 'cause its faster!"

(C)  As you say, FTP isn't TCP.   Also when you start talking about file transfer, or anythign that can be buffered (like video streams)  bandwidth is usually much more important then latency.  People often confuse the two but they are very different quantities and have very different effects.  Game packets on the other hand are usually more latency then bandwidth sensative.

(D) Foward Error Correction makes a lot of sense I think where the data stream is well known into thge future, but again game packets usually arent that way.

(E) Lastly video ofcourse can handle some loss and error so perfect error correction isnt necessary.  A proper video protocol can make good use of that.  Again this generally isnt true for your game data stream.

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 Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #108 - Posted 2003-11-26 06:20:52 »

Quote

People often confuse the two but they are very different quantities and have very different effects.  Game packets on the other hand are usually more latency then bandwidth sensative.


But one has to keep in mind that bigger messages (-> bandwidth) esp. on very thin lines add their part to latency, bc. it just takes longer to transmit them! Another 100byte on an ancient 14k modem causes ~100ms on pure transmission time which adds to the other sources of latency. 100ms!

Addtionally, bandwidth gets more important when talking about MMP things.

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

JGO Coder




Got any cats?


« Reply #109 - Posted 2003-11-27 01:30:06 »

Quote


But one has to keep in mind that bigger messages (-> bandwidth) esp. on very thin lines add their part to latency, bc. it just takes longer to transmit them!


True they are related, particularly on thin analog lines.

But in fact the relationship is significantly more complex.

In order to get above 28.8K the modems do compression and decompression, so upping the bandwidth actually UPS the latency as that takes time.

Even worse, the faster you try to run the analog modem the more likely it is to fail due to noise and have to fall back and find a new speed to communicate at.  These retrains can take 6 or 8 SECONDS.

So trying to push the bandwidth to high on a thin analog line actually makes your latency problems much worse.

(I'm about to write a chapter about all of this it looks like for Shawn's book...)

As for MM, that totally depends on your communication architecture.  You can do a lot to limit that by NOT sending players info they aren't in a position to use.  The cost ofcourse is more complex processing on the server.

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 swpalmer

JGO Coder




Where's the Kaboom?


« Reply #110 - Posted 2003-11-27 04:37:03 »

Quote
I *think* your video protocol gets us back to initial contentions.

(A) if you don't need reliable or in order devliery then by all means use UDP (unless you have serial PPP bandwidth issues.)  Thats what its for!


I think you may have read more into what I said.  The sending of these large video files must be reliable and bit for bit accurate.. this is not for broadcasting, it is for arbitrary file copying.. video files are just what we happen to be transferring.

Quote
(B) For very domain specific things... you can improve on TCP....

But its a lot of work and requires a pretty deep understanding of how the net actually functions.  People who just slap a simple reliability/ordering protocol on top of UDP are reinventing the wheel and end up only hurting their performance.


I agree 100%

Quote
Unfortunately, that last is the most common occurance in games that decide to "use UDP 'cause its faster!"

Quote
(C)  As you say, FTP isn't TCP.   Also when you start talking about file transfer, or anythign that can be buffered (like video streams)  bandwidth is usually much more important then latency.  People often confuse the two but they are very different quantities and have very different effects.  Game packets on the other hand are usually more latency then bandwidth sensative.

Right,  My point on game packets is that in the event of an error along the data path, TCP will correct that at the expense of both bandwidth and latency.  If your packet has to get through though TCP will probably do the best job and so you just have to live with what you get.  However, depending on the size of the game state, it may make sense to send enough of it such that it does not matter if previous packets made it through, or the error that results would not be objectionable to matter and will correct itself when another few packets make it through.

With a little thinking ahead you may come to the conclusion that order of delivery and guaranteed delivery don't actually help you.  The state of the client won't be 'wrong' long enough to matter, or the packets that TCP will send to correct the 'problem' are just getting inserted in the stream and delivered to the client when the next packet that supersedes that state is already waiting in the clients network buffer anyway.  It's just something to think about..  you could probably calculate how useful it is to consider these things when you work out the ping vs. bandwidth and try to determine the time it takes to correct for a lost packet vs. the time it takes to get the next newer packet of game data.

Quote
(D) Foward Error Correction makes a lot of sense I think where the data stream is well known into thge future, but again game packets usually arent that way.

I agree.. I initally stated as much, saying that this UDP+FEC idea might be useful for downloading models, patches, level etc.  but not dynamic game state.

Quote
(E) Lastly video ofcourse can handle some loss and error so perfect error correction isnt necessary.

I should have just said "big files" there was no data loss allowed.

Quote
In order to get above 28.8K the modems do compression and decompression, so upping the bandwidth actually UPS the latency as that takes time.

But compression happens almost instantly relative to the slow speed of the transmission.  Recall that the link between modem and CPU is MUCH faster than the phone line.. the data would be sitting in the modems buffer waiting to get out anyway - so compression happens for free - when it is done by the modem hardware, and not some crappy winmodem with all the work done  by the CPU.. so does this not ultimately save latency via the methods Herkules mentioned by delivering a shorter packet?
 
Quote
Even worse, the faster you try to run the analog modem the more likely it is to fail due to noise and have to fall back and find a new speed to communicate at.  These retrains can take 6 or 8 SECONDS.

Ah but your game, these days, has no control over the speed that the modem attempts to connect at.   So re-trains do to line noise etc are just going to happen.. the only thing that your program can control that I could thnk might effect it is that it might not know that it has to retrain until you actually send data for it to barf on.. so by that account the more data you send the more opportunity it would have to realize the connection is crap.   But as for speed that the data travels - that is usually beyond the control of applications.  The dial-up networking layer will deal with it.

Offline Jeff

JGO Coder




Got any cats?


« Reply #111 - Posted 2003-11-27 08:43:57 »

Lots  of agreement here, a few minor points.

Quote

But compression happens almost instantly relative to the slow speed of the transmission.  Recall that the link between modem and CPU is MUCH faster than the phone line.. the data would be sitting in the modems buffer waiting to get out anyway - so compression happens for free - when it is done by the modem hardware,


If this is true today then modems have GREATLY improved their processing power in the last few years.

Remember in return that embedded hardware is HIGHLY cost sensitive.  The cheapest parts that will do the job are always used because a $1.00 part cost difference easily becomes a $10.00 shelf cost difference, which will lose you sales v. a competitor who is that much cheaper.  (My days at Philips are showing here Wink )

When I was at TEN, which was 5 years ago, asking the modem to go over 28.8 *definitely* added signficant latency which is why we never did it.

Quote

Ah but your game, these days, has no control over the speed that the modem attempts to connect at.  


At TEN we set it via Win32 APIs.

From Java yes you might have to write some native hooks OR simply run the RECIEVING modems at a limited speed, if you have control over that end (we didn't.)

At worst case, you make it part of your "what tp do if the game dossn't work well" instructions and tell the user how to set it in the target OS.  (We did this too, advising uses to back off the speed further if they had very dirty lines.)

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 Jeff

JGO Coder




Got any cats?


« Reply #112 - Posted 2003-11-27 08:48:30 »

A few more comments..

Quote
With a little thinking ahead you may come to the conclusion that order of delivery and guaranteed delivery don't actually help you.  The state of the client won't be 'wrong' long enough to matter,


This MAY be true depending on the type of game.  I could see it, for instance, in a racing game.

Many games however contain SOME packets that need to be delivered reliably in a timely manner.  Shots for instance in any kind of shooter.

Once you have ANY packets that require this, it means you need to solve the speed problem for reliable packets, you don't have a choice.  And once you've solved that problem, doing a second unreliable channel is generally needlessly redundant and just doubling your effort for no end gain.


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 Jeff

JGO Coder




Got any cats?


« Reply #113 - Posted 2003-11-27 08:52:27 »

Oh and just to further complicate things...

On those thin analog lines remember you are running serial PPP, which means that the overhead for a UDP packet (30 bytes) is 15 times larger then for a TCP packet (2 bytes.)

As I think I mentioned this was a large part of why we were TCP based at TEN.

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 Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #114 - Posted 2003-11-27 09:57:56 »

Kiss

how I love to hear you saying that....

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

JGO Coder




Where's the Kaboom?


« Reply #115 - Posted 2003-11-27 14:08:41 »

Quote
If this is true today then modems have GREATLY improved their processing power in the last few years.


I could be completely wrong about the compression thing.  I am making some assumptions about the speed of modems the implement the compression on-board and comparing what I'm guessing to be the speed of on-board compression to the relatively snail-like pace of the modem's outgoing analog transmission.[/quote]

Quote
At TEN we set it via Win32 APIs.


You modified the parameters of the users dial-up netowrk connection?  Or was this in the days of modem to modem, i.e. non-internet, network gaming?  As long as you set the network settings back the way they were I guess it isn't a problem... still seems scary to me though - what if you crashed before you could restore the settings?

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #116 - Posted 2003-11-27 14:17:08 »

Quote
On those thin analog lines remember you are running serial PPP, which means that the overhead for a UDP packet (30 bytes) is 15 times larger then for a TCP packet (2 bytes.)

Right, but much of what I've been saying (UDP+FEC, TCP throughput bounds due to ping time and ack windows), applies mainly to higher speed connections, not serial PPP (does PPPoE have the same advantage?).  I'm basing my comments on broadband, which will be the majority of on-line users in North America soon enough.  (well before I complete a project, that's for sure Smiley!)

Quote
As I think I mentioned this was a large part of why we were TCP based at TEN.

Yeah you've said that a zillion times Smiley

Like you said you uses a combo of TCP and UDP at TEN (too many TLAs there!).  You have to think about what you are trying to accomplish and use each where appropriate.. e.g. TCP for the client to tell the server that it shot,  UDP for the server to tell all the clients where to draw your rocket.

Offline Jeff

JGO Coder




Got any cats?


« Reply #117 - Posted 2003-11-27 18:42:56 »

Quote
Like you said you uses a combo of TCP and UDP at TEN (too many TLAs there!).  


Actually no, you misunderstood me.

We were TCP based.  We eventually developed a special hybrid protocol that used UDP to help certain conditions that occur during TCP for some specific games like Quake2.  It wasn't on the game-logic level.  It was much lower, and really a way of augamenting TCP at the protocol level.

And thus my point was that you need to really understand whats happening at that level to make such domain specific custom hybrid protocols really work.

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 #118 - Posted 2003-12-01 19:08:11 »

Quote

For the record, my company has just licensed a UDP-based transporter that uses FEC and in real world tests we are seeing significant gains over TCP (50% + just from Texas to Toronto where there is almost 0 packet loss and ping <=100ms).  We need to move large video files from one side of the world to another.  The speed ups can be VERY substantial (500%) with even a little bit of packet loss.

*edit*  I'm comparing to regular FTP - which is not the fastest TCP based transfer protocol.


Out of interest, whose implementation(s) of TCP/IP stacks are you using? How good is the hardware and software? Also, just how much less than 100ms is your ping time Smiley ? And what bandwidths are you getting a 50% increase on?

I only ask because IME TCP has been very good to me in very low packet-loss very high bandwidth situations, although 100 ms sounds very high (I would expect to get significantly less than that trans-atlantic, IIRC?). At the same time, bad implementations of TCP have been excrutiatingly painful; back in the days of MSIE4 I used to encourage people to compare large high-bandwidth downloads via HTTP and then again via FTP and THEN with a specialist download client just to convince them that there were some seriously rubbish systems and protocol implementations around...(although I never dug deep to find out the precise causes of the differences in particular cases).

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

JGO Coder




Got any cats?


« Reply #119 - Posted 2003-12-01 20:53:21 »

Quote
You modified the parameters of the users dial-up netowrk connection?  Or was this in the days of modem to modem, i.e. non-internet, network gaming?  As long as you set the network settings back the way they were I guess it isn't a problem... still seems scary to me though - what if you crashed before you could restore the settings?


This was over the internet using standard analog POPs.

AIR we created a new connection called something like "TEN Connection" that we referenced from the terminal program when we opened the connection to the POP.


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
Pages: 1 2 3 [4] 5
  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.

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

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

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

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

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

Riven (48 views)
2014-07-14 18:02:53

OpenGLShaders (38 views)
2014-07-14 16:23:47

Riven (37 views)
2014-07-14 11:51:35

quew8 (33 views)
2014-07-13 13:57:52

SHC (70 views)
2014-07-12 17:50:04
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!