14 Mar, 2010, Blinx wrote in the 1st comment:
Votes: 0
Ok. So I've looked around and found a commercially available network library which handles TCP and UDP both at the same time.

Basically, a server utilizing this library would use UDP as a standard transfer protocol and TCP to make sure that there isn't a loss of parcels in between.


Any thoughts on the viability of this? Would it be a good idea to use this for a custom code-base (I can only imagine how it would speed things up) or should I rather stick to standard winsock TCP/IP for security reasons?
14 Mar, 2010, Cratylus wrote in the 2nd comment:
Votes: 0
Blinx said:
use UDP as a standard transfer protocol


transfer protocol for exactly what kind of traffic?
14 Mar, 2010, shasarak wrote in the 3rd comment:
Votes: 0
TCP/UDP? That's a weird combination. The two are generally used in entirely different situations. TCP is used when you want to ensure that the data makes it through intact, and it doesn't matter if there's a bit of a delay involved as a consequence. UDP is used when it is more important for the data to get there in real time than it is for it to get there in one piece - so, with voice over IP, for example, it might be preferable for part of the signal to get lost rather than to introduce a time-lag.

The two things would seem to be mutually contradictory.
14 Mar, 2010, Blinx wrote in the 4th comment:
Votes: 0
Cratylus said:
Blinx said:
use UDP as a standard transfer protocol


transfer protocol for exactly what kind of traffic?


Here are 2 links to the library.
I'm not really that good at explaining technical stuff, I suppose.


http://forum.thegamecreators.com/?m=foru...
http://darkbasicpro.thegamecreators.com/...


Quote from Michael "Mike" P (the author of Mikenet/Darknet)

Quote
Yes, MikeNet does most of the work for you with TCP and UDP.

With UDP when you call mnRecvUDP only the latest packet for that client or client operation will be received. Old packets are discarded between each mnRecvUDP call.

With TCP older packets are stored and when you call mnRecvTCP you are retrieving the oldest packet that has been received since the last mnRecvTCP.

Page two of the documentation (inside the version 1.0 zip) outlines the way in which the TCP and UDP systems work.



@shasarak

My exact thoughts. That's why I'm curious. Never heard of someone using this combination.
14 Mar, 2010, Cratylus wrote in the 5th comment:
Votes: 0
Blinx said:
Cratylus said:
Blinx said:
use UDP as a standard transfer protocol


transfer protocol for exactly what kind of traffic?


Here are 2 links to the library.
I'm not really that good at explaining technical stuff, I suppose.


http://forum.thegamecreators.com/?m=foru...
http://darkbasicpro.thegamecreators.com/...


Those links are your homework, not mine.

If you can't answer the question of what the UDP is for, and you
can't properly formulate a question as to whether you need it
because of that, then maybe you should keep reading the
docs until you can communicate your ideas in a way others
can understand.

It looks to me like you're asking "should i use this software for
my awesome graphical mud idea?".

The answer to that is "try it and see".

-Crat
http://lpmuds.net
14 Mar, 2010, Blinx wrote in the 6th comment:
Votes: 0
Cratylus said:
Blinx said:
Cratylus said:
Blinx said:
use UDP as a standard transfer protocol


transfer protocol for exactly what kind of traffic?


Here are 2 links to the library.
I'm not really that good at explaining technical stuff, I suppose.


http://forum.thegamecreators.com/?m=foru...
http://darkbasicpro.thegamecreators.com/...


Those links are your homework, not mine.

If you can't answer the question of what the UDP is for, and you
can't properly formulate a question as to whether you need it
because of that, then maybe you should keep reading the
docs until you can communicate your ideas in a way others
can understand.

It looks to me like you're asking "should i use this software for
my awesome graphical mud idea?".

The answer to that is "try it and see".

-Crat
http://lpmuds.net




I know what UDP is for. It's negatives (mainly the packet loss and field restriction) and positives (quite a bit faster than TCP) . That's what it makes it so hard to believe that it would actually work with TCP software, which is slower than UDP but allows a higher count of users a time and is safer.

The only reason I posted it here is out of curiosity. I thought that perhaps someone did it before.


I'm pretty much blind coding, at the moment (MacOSX with no admin rights and therefore no possible way to use virtualization or install anything aside of an IDE. You get the idea)
14 Mar, 2010, Tyche wrote in the 7th comment:
Votes: 0
Blinx said:
Any thoughts on the viability of this? Would it be a good idea to use this for a custom code-base (I can only imagine how it would speed things up) or should I rather stick to standard winsock TCP/IP for security reasons?


I'm quite certain it uses Winsock under the covers when running on Windows. It probably exposes a higher-level and friendlier interface.. maybe an event framework. And it appears there are a number of bells and whistles, uPnP, encryption, etc. that you may or may not use which you'd end up writing yourself.

The UDP v. TCP question…both are available in Winsock. Some muds use UDP for various things. CoolMud uses UDP in it's YO protocol which is a distributed mud protocol. Some features of the Intermud3 protocol use it on LPMuds. Genesis/ColdC server implements it, but I can't remember what they were using it for.

Generally UDP is used for information that can survive packet loss. Graphical muds like Ultima Online/WoW/etc. use it to send updates of positions to clients. That's why on a really bad connection, one reason you might see your character or other characters seeming to leap from position to position, is because the UDP data went missing. There may be other reasons for this.

Sound and video transmission is often done via UDP.

I played around with UDP to gather info from a stock ticker feed, thinking I could use the noise in a game that's still on hold. ;-)
14 Mar, 2010, Cratylus wrote in the 8th comment:
Votes: 0
Quote
The only reason I posted it here is out of curiosity. I thought that perhaps someone did it before.


Ok, check it out. I like you. Like. I like you!

You appear bright, motivated, and enthusiastic. I love that stuff, and I
like that you're adding your postological distinctiveness to the MudBytes
collective. You're a win-win.

Let me say something that I hope will be helpful, but might start off
sounding a little bit mean.

This isn't the first thread in which you, as a new guy, ask about something
that you really don't know too much about, in terms that make it clear
you basically need a tutorial in order to ask the question you really
mean to ask. There's no fault in that. We've all been there. It's just
a natural part of being the new guy.

Here's where you're a little off, though…you know that thing you just
said, about just being curious, and you can't really code anything right
now? That's the sense you've been giving off for a while now. "Idle Curiosity"

Generally there's nothing wrong with that, but take, as an example, the
Diku thread you were recently in. You could have simply done your homework,
read through the umptillion posts here and on TMC and on TMS about this,
and come to the exact same conclusion…"huh. Maybe I'd best forget about
money stuff". Instead, your (completely innocent) blundering kicked off
Yet Another Dreadful Licensing Seizure, that even triggered the tearing
open of scabs on another site.

That wasn't your fault. That was Tyche. But my point is that your
thrashing around as a bored newbie that is idly curious has effects on this
forum when you use it in the manner of a chat room….and it's not a
chat room. People here tend (this author excluded of course) to spend
time composing thoughts and getting personally invested in replies here.
If you're asking semi-pointless stuff you don't understand because you're
"just curious", weird shit can happen. c.f. Iguanarage.

My suggestion is that you get onto IMC2 and use that for you idly curious
questions. People there are very receptive to idle boredom and curiosity.
It's largely the rule. On IMC2 if you happen to step on a sacred cow
because you're bludering around, the response is limited to the localized
immune response…rather than risking metastasis across websites and
permanent archival with you as catalyst of mudstorm 3,263,827.

Note please that I'm not telling you to STFU. Nor am I saying that MB
is some kind of critically dangerous minefield to be navigated only by
experts. I am saying, though, that there is a better place for idle
curious chat: http://imc.mudbytes.net/logs/ichat/1000/...

-Crat
http://lpmuds.net
14 Mar, 2010, Blinx wrote in the 9th comment:
Votes: 0
Ok. Apparently, that's the main reason for a combined TCP/UDP protocol:


Quote
arkNet's instance system allows you to create and control multiple connections. This means that a single application can host and connect to multiple servers at the same time. This dramatically increases the options available to you. Here are some options that this feature opens up to you:

- Use of peer to peer so that a single user leaving will not cause disconnection of other clients. Using traditional client/host setup, if the host shuts down then all connected clients lose connection.


Doesn't apply here, of course. It's not a FPS, after all.

Reading from some other sources, it sounds like TCP and UDP can actually hinder each other (worst case scenario: TCP increasing the packet loss of UDP packets)


@Tyche

Are you sure MMOs like World of Warcraft or Ultima Online use UDP? From what I know (from the Blizzard site) World of Warcraft uses TCP for most everything except in-game voice-chat, which is UDP based.
14 Mar, 2010, Blinx wrote in the 10th comment:
Votes: 0
Sorry. Went for a late lunch and missed your post, Crat.


I understand you (no hard feelings from my side).

I suppose I'm just a bit too talkative, in some occasions (my personal forum record is 2800 posts in 1 month, three years ago on another board).

I'll try to step some steps back, on that.


Where I don't agree with you, though. You said "Idle Curiosity". I might be curios but I actually do work around things. There's quite a difference between idle curiosity and blind coding, I'm afraid.

While I might not have a compiler, I can still code quite a bit. It's a bit on the rough side (no intellisense, no colour scheme) but usable, as long as you remember the basics.

Just for you, Crat:

14 Mar, 2010, Deimos wrote in the 11th comment:
Votes: 0
WoW is an atypical case. Most graphical games use UDP for real-time position updates. In fact, most MMOs use a TCP/UDP combination, because some data needs to get to the client and some doesn't. Without knowing what it is that you're doing, the best answer anyone can give you is "it depends."

To be honest, if you aren't wholly familiar with networking and the why's and why not's, I would advise you to stick with TCP, regardless. It's actually harder to learn, since you have to manage connections, but in the end, you'll avoid all the headaches that come with an undependable protocol. Plus, anything you can do with UDP, you can also do with TCP. When and if performance becomes an issue, and you've learned how to mitigate it by using a different protocol, then you can look into doing something different.

IMHO.
14 Mar, 2010, David Haley wrote in the 12th comment:
Votes: 0
Basically the problem here is that you're asking a question that is impossible to answer short of stepping back and explaining the theory of TCP vs. UDP, as several have done before.

You're saying:
- I have a game of unknown characteristics (to us, the readers of your post)
- It does some stuff
- I have stuff to do on a network
- Should I use TCP or UDP or both on my custom game?

The only possible answer to this question is "it depends". In fact, the very first question you got was "what kind of traffic are you dealing with", which you couldn't answer. That you don't even know the traffic you'll be handling is an indication that you shouldn't yet be asking this question, but should instead be asking "what is the difference and why do people care"?


But no, UDP is not "faster" than TCP in the sense that UDP packets will somehow whiz along the network more rapidly. UDP is "faster" only in the sense that if a packet is lost, subsequent packets still arrive on the other end.

There's no reason you couldn't implement TCP on top of UDP (incidentally, that is what the notation TCP/UDP would mean, and I'm not sure if that's what you meant). It would be kind of silly because that's what TCP/IP basically does, but… well.

I think what Crat meant is that people like to know the seriousness/interest level of the person they're replying to. To give my personal story, I don't really like to spend time writing up detailed explanations if I get the impression that the person on the other end is asking whimsical questions. I think that other people behave similarly.

So in the interests of expediency: is there still a question to be answered here or has the curiosity been sated?
14 Mar, 2010, Blinx wrote in the 13th comment:
Votes: 0
David Haley said:
Basically the problem here is that you're asking a question that is impossible to answer short of stepping back and explaining the theory of TCP vs. UDP, as several have done before.

You're saying:
- I have a game of unknown characteristics (to us, the readers of your post)
- It does some stuff
- I have stuff to do on a network
- Should I use TCP or UDP or both on my custom game?

The only possible answer to this question is "it depends". In fact, the very first question you got was "what kind of traffic are you dealing with", which you couldn't answer. That you don't even know the traffic you'll be handling is an indication that you shouldn't yet be asking this question, but should instead be asking "what is the difference and why do people care"?


But no, UDP is not "faster" than TCP in the sense that UDP packets will somehow whiz along the network more rapidly. UDP is "faster" only in the sense that if a packet is lost, subsequent packets still arrive on the other end.

There's no reason you couldn't implement TCP on top of UDP (incidentally, that is what the notation TCP/UDP would mean, and I'm not sure if that's what you meant). It would be kind of silly because that's what TCP/IP basically does, but… well.

I think what Crat meant is that people like to know the seriousness/interest level of the person they're replying to. To give my personal story, I don't really like to spend time writing up detailed explanations if I get the impression that the person on the other end is asking whimsical questions. I think that other people behave similarly.

So in the interests of expediency: is there still a question to be answered here or has the curiosity been sated?


Slight correction. I never even considered using UDP alone, neither stated it this way.

My question was purely made under the assumption that someone might know or use a server with a combination of TCP and UDP, since I've never heard of this combination before (before I stumbled across the Darknet/Mikenet library).

That's why the title says "TCP vs TCP/UDP" not "TCP vs UDP vs TCP/UDP", btw.


But yes. Everything has been answered.
14 Mar, 2010, David Haley wrote in the 14th comment:
Votes: 0
Oh well, I guess it was unclear to me what you meant when you said that it would "use UDP as a standard transfer protocol".
14 Mar, 2010, Blinx wrote in the 15th comment:
Votes: 0
David Haley said:
Oh well, I guess it was unclear to me what you meant when you said that it would "use UDP as a standard transfer protocol".


That was my understanding of how the whole Darknet library worked. Before I found the right paragraph in the documentation.

From the description, it sounded like those parcels would be delivered via UDP and then some routine would check for lost parcels and fill the gap via TCP. Weird idea, I know.
15 Mar, 2010, kiasyn wrote in the 16th comment:
Votes: 0
David Haley said:
Basically the problem here is that you're asking a question that is impossible to answer short of stepping back and explaining the theory of TCP vs. UDP, as several have done before.

You're saying:
- I have a game of unknown characteristics (to us, the readers of your post)
- It does some stuff
- I have stuff to do on a network
- Should I use TCP or UDP or both on my custom game?

The only possible answer to this question is "it depends". In fact, the very first question you got was "what kind of traffic are you dealing with", which you couldn't answer. That you don't even know the traffic you'll be handling is an indication that you shouldn't yet be asking this question, but should instead be asking "what is the difference and why do people care"?


But no, UDP is not "faster" than TCP in the sense that UDP packets will somehow whiz along the network more rapidly. UDP is "faster" only in the sense that if a packet is lost, subsequent packets still arrive on the other end.

There's no reason you couldn't implement TCP on top of UDP (incidentally, that is what the notation TCP/UDP would mean, and I'm not sure if that's what you meant). It would be kind of silly because that's what TCP/IP basically does, but… well.

I think what Crat meant is that people like to know the seriousness/interest level of the person they're replying to. To give my personal story, I don't really like to spend time writing up detailed explanations if I get the impression that the person on the other end is asking whimsical questions. I think that other people behave similarly.

So in the interests of expediency: is there still a question to be answered here or has the curiosity been sated?


well technically UDP does have smaller headers IIRC
15 Mar, 2010, David Haley wrote in the 17th comment:
Votes: 0
I'm assuming you're answering to the one sentence regarding speed, not the whole post. UDP headers are 32 bits whereas TCP is 128, or more if there are header options. I'm not sure if you're arguing that a difference of (128-32)/8=12 bytes is going to make any kind of noticeable difference in speed?
15 Mar, 2010, quixadhal wrote in the 18th comment:
Votes: 0
shasarak said:
TCP/UDP? That's a weird combination. The two are generally used in entirely different situations. TCP is used when you want to ensure that the data makes it through intact, and it doesn't matter if there's a bit of a delay involved as a consequence. UDP is used when it is more important for the data to get there in real time than it is for it to get there in one piece - so, with voice over IP, for example, it might be preferable for part of the signal to get lost rather than to introduce a time-lag.

The two things would seem to be mutually contradictory.


Nope, not at all. The two are quite often used side-by-side in graphical MMO's. You keep a TCP channel open to handle commands, chat, and other services that you always want to get through. You use UDP for things like position updates and more ephemeral data. If you miss a position update, the next one will simply have a larger delta so your client-side smoothing might have a slight jump when it corrects.
21 Mar, 2010, Tyche wrote in the 19th comment:
Votes: 0
Yes UDP is faster than TCP, but not because of the packet size nor because the packets somehow travel faster.
It's because multiple TCP packets are exchanged between client and server while transmitting data.
21 Mar, 2010, David Haley wrote in the 20th comment:
Votes: 0
That doesn't necessarily make it faster. As long as packets continue flowing, and there isn't loss, the acknowledgments won't necessarily be slowing you down.
0.0/52