UDP/TCP Hybrid Game

[Matt2]

I don't know where I read this, or if it's even on this forums. All I know is that, I got the idea to try and mix the two up. I've gotten some comparisons and reading done. I know it's been done, for the article I read on it said so, but I want to try and implement that onto MS.

I'm sure, by now, we all know the difference between TCP and UDP. TCP being reliable but slow, and UDP being unreliable but fast. But for those who don't know why, here are the comparisons taken from Wikipedia:

Difference between TCP and UDP

TCP is a connection-oriented protocol, a connection can be made from client to server, and from then on any data can be sent along that connection.
Reliable - when you send a message along a TCP socket, you know it will get there unless the connection fails completely. If it gets lost along the way, the server will re-request the lost part. This means complete integrity; things don't get corrupted.
Ordered - if you send two messages along a connection, one after the other, you know the first message will get there first. You don't have to worry about data arriving in the wrong order.
Heavyweight - when the low level parts of the TCP "stream" arrive in the wrong order, resend requests have to be sent, and all the out of sequence parts have to be put back together, so requires a bit of work to piece together.
Streaming - Data is read as a "stream," with nothing distinguishing where one packet ends and another begins. May be multiple packets per read call.

UDP is a simpler message-based connectionless protocol. With UDP you send messages(packets) across the network in chunks.
Unreliable - When you send a message, you don't know if it'll get there, it could get lost along the way.
Not ordered - If you send two messages out, you don't know what order they'll arrive in.
Lightweight - No ordering of messages, no tracking connections, etc. It's just "fire and forget"! This means it's a lot quicker, and the network card / OS have to do very little work to translate the data back from the packets.
Datagrams - Packets are sent individually and are guaranteed to be whole if they arrive. One packet per one read call.

The idea of using UDP to replace TCP is insane! But, using UDP to send packets that don't really matter as much, might be a better approach at making a faster game, reducing the 'stream', as it's refered to, of data.

I am currently working on research and seeing if it could even be done to Visual Basic. It should, so, using it for MS would help, no? Especially for things like player movement.

Anyways, keep checking back. I will be updating this post with my finds, and if I fully implement it, I will be updating with the code.

Thank you guys for reading! I hope this helped some of you understand UDP better, and also understand TCP as well!

[Robin]

Using it for 'less important' packets? That's gonna be a bitch when trying to do something.

[Matt2]

I'll have to work on that part...

-.-

[William]

Moved to Knowledge Base.

[Coke]

Well to be honest the way things are going, i dont think uber speedy packets and such are going to be that important on a program such as MS. PC's are getting more powerfull, internet speeds are getting faster...

I wish we could learn what kind of systems WoW and Guild wars use, especially Wow; so many packets must be being sent its insane o.0

[Spodi]

WoW uses TCP. TCP/UDP hybrids are hardly worth it for a 2d ORPG. Many 3d MMORPGs use TCP. The packet speed isn't that important, just fluency and smoothness.

[Spodi]

But then again, its probably a poor network structuring to be sending them their health every 5-10 seconds. :wink:

You could do it for values like positioning and stats and such, but a lot would probably just go to waste. I may just think too much in a TCP style, though, since thats what I use from day-to-day. If you work at it hard so you can support packets coming in the wrong order, a reliable UDP would be nice, since then you can throw in that the TCP/IPv4 headers are 40 bytes while UDP/IPv4 are only 28 per packet, plus the UDP would be getting there faster (just not in order as often).

Either way, overkill for MS. :wink:

[Coke]

What if key points are 'flagged' in the code, for example all the instances where a players health could change, i am all for sending packets only when needed... packet spamming makes me want to cry, but sending packets on the event is so tedious...

Sub PlayerHPChange() for the win xP

[Spodi]

Thats what I did, and it seems to work pretty well. Keep a variable for every stat that needs to be updated when it changes. Every time you assign a value to the stat, check if it is a new value. If so, set the changed flag to true. Then, every few hundred milisecs, check through all the variables and see if you need to update.

[Coke]

Would you be able to give me a code overview of how you have done that? Sounds quite effective

[Spodi]

Well you can just check vbGORE's server code. 8) But basically, there is in a class module an array for the stats (can also work with just individual stat names) and a byte for each one that states if it was updated. Since it is a class module, every time the stat is changed, you can catch it (Property Get or Let, forget which one). Then just do a quick check, "If OldValue NewValue Then Update(Index) = 1". Then add a timer that runs through and checks if the Update(Index) = 1, then update accordingly. :wink: