Handle players in online games.

[Mirror]

Reliability is up? Well, I'm glad you've started out by making an argument in favour of using UDP.

true but only partially as during a temporarily lack of reliability, udp will be the first to suffer since it's just a best-effort protocol ( no resending in case of failure ). On the other hand tcp will still work even on low reliability connections.

TCP sucks. It's inherently slower, since most routers prioritise UDP traffic. TCP/IP has (at least) 40 bytes of overhead per payload packet, compared to 28 for UDP/IP. TCP can be spoofed easily with a man-in-the-middle attack.

it is slower, but that was more obvious in the 80s where the lucky guys had a 33.3Kbps dialup. TCP cannot be as easily be spoofed as UDP. you need sequence numbers, you need to truly be a man in the middle ( router ) etc. On the other hand, UDP is trivially spoofed since there is no such thing as a connection and thus you can send whatever packets you want from whatever source address you want and guess what? the server will happily accept them. Unless of course you implement - through some kind of higher level wrapper - some basic security features, which ofcourse wouldn't be needed to be implemented if you used TCP in the first place because they are inherent in it.

Oh, sure, TCP is fine for MUDS, or whatever those crazy kids are calling their PBEM games these days.

that's true and the guy had already mentioned in the begining that his game is an ORPG, so :p

Perhaps one doesn't need all of one's communication to be reliable, and would prefer to avoid the inherent overhead of TCP and the unavoidable overhead of invisible resends?

well if he wants to go commercial he will want to be reliable and secure, but yes for really real-time communications udp is better as it is faster.

TCP is far easier, since it deals with sequencing and reliability internally. That's why libraries like Raknet and more specifically Enet exist, to implement reliable UDP that's as simple to use as TCP.

if you need asynchronous sockets, doesn't that alone make it more difficult ? with udp you just send packets to a port, with tcp you need to configure several more flags

Counterstrike? Y'all from the future? Time from an anecdote, from the Early Olden Days.

'Roger' was my original Netrek handle from the early 1990s. I changed it to 'Rogerborg' when I wrote a (cy)borg client that successfully hacked its way into the server, using (can you guess?) a man-in-the-middle attack on the TCP communication between client and server.

I wouldn't call it trivial, but it's not far off.

Any argument that a TCP communication can be authenticated, well... I'm in the middle. The slave client is going to authenticate it for me. The communication has to be encrypted to be secure from a MitM TCP attack, and if it is, then that makes it equally secure from UDP spoofing, doesn't it?

for each communication service ( be it game or IM or anything else ) that you can name that has cheats that exploit the TCP protocol ( not to be confused with the GAME/service protocol ), i will name at least 3 ( initially i wanted to say 10 but i lowered the number because it's hard anyway to find many which use UDP ) which have cheats which exploit UDP

your turn now

[rogerborg]

[To spoof TCP] you need sequence numbers, you need to truly be a man in the middle ( router ) etc.

If we're doing it locally, then how about if we simply hijack the socket function calls from under the client before they even hit the OS, and manipulate the TCP stream content directly?

Sounds tricky? Just inject a DLL or for that matter simply drop a shim DLL in the app's directory. Job done.

On the other hand, UDP is trivially spoofed since there is no such thing as a connection and thus you can send whatever packets you want from whatever source address you want and guess what? the server will happily accept them.

And do what with them? If by "spoofing" you mean impersonating another remote player, how are you getting their source IP? No reasonable client/server implementation will reveal that to you, and good luck guessing it. If they're on a local LAN, then you might as well pull their network cable out - ah, fond memories of inter-office GTA 1 deathmatches.

If you mean injecting packets from a 3rd party application into your regular client's datastream using your own source IP, then UDP does already provide one hurdle: since it's unreliable, all real implementations (Raknet, Enet, IrrNet etc) are at an absolute minimum already putting packet sequence numbers in the payload anyway. Good luck guessing a sensible one. Of course, you could always just hijack the socket calls, same as with TCP.

Raknet also provides encrypted UDP packets, which raises the bar even higher. Since Raknet exists, this isn't a theoretical issue. I'm comparing TCP against (e.g.) Raknet, not TCP against UDP.

Perhaps one doesn't need all of one's communication to be reliable, and would prefer to avoid the inherent overhead of TCP and the unavoidable overhead of invisible resends?

well if he wants to go commercial he will want to be reliable and secure,

I re-iterate. Perhaps one doesn't need all of one's communication to be reliable. Some packets (say, non-critical state updates for distant mobs in your MUD) you can afford to lose. UDP lets you choose to do so, saving you bandwidth: TCP does not, and will always resend them.

if you need asynchronous sockets, doesn't that alone make it more difficult ? with udp you just send packets to a port, with tcp you need to configure several more flags

Code: Select all

unsigned long on = 1;
ioctl(sock, FIONBIO, &on);

Works For Me. TCP does have the issue that you can and will receive partial packets inside the stream, which does need handling, but doing so is simpler than layering reliability over UDP.

However, since I'm comparing Raknet to TCP, it's not hard at all, since Raknet is already doing it.

Wait, I forgot what side I was arguing there.

for each communication service ( be it game or IM or anything else ) that you can name that has cheats that exploit the TCP protocol ( not to be confused with the GAME/service protocol ), i will name at least 3 ( initially i wanted to say 10 but i lowered the number because it's hard anyway to find many which use UDP ) which have cheats which exploit UDP

your turn now

Off the top of my head: Netrek; XPilot; Navy Field. I won't hold you to a list of 9 though, because it's an irrelevant issue. Any app that uses TCP can be exploited, unless it uses the same technique (encrypted payload) that would protect a UDP app.

Crib notes: I know that it's easy to hijack a TCP connection, because:
1) I have done it, repeatedly, and
2) I am lazy, and wouldn't bother doing it if it were hard.

[Mirror]

If we're doing it locally, then how about if we simply hijack the socket function calls from under the client before they even hit the OS, and manipulate the TCP stream content directly?

Sounds tricky? Just inject a DLL or for that matter simply drop a shim DLL in the app's directory. Job done.

yes but that requires that you have access to the client machine. hijacking the sockets before even hitting the OS assumes that you have admin/root access in the target machine which is not the case we are discussing here

If you mean injecting packets from a 3rd party application into your regular client's datastream using your own source IP, then UDP does already provide one hurdle: since it's unreliable, all real implementations (Raknet, Enet, IrrNet etc) are at an absolute minimum already putting packet sequence numbers in the payload anyway. Good luck guessing a sensible one. Of course, you could always just hijack the socket calls, same as with TCP.

Raknet also provides encrypted UDP packets, which raises the bar even higher. Since Raknet exists, this isn't a theoretical issue. I'm comparing TCP against (e.g.) Raknet, not TCP against UDP.

yes exactly you are comparing tcp to raknet which is not fair. i wanted to mention this before in my previous post but i was hasty to leave from work. If TCP=Woman and UDP=Man then raknet is a transvestite : it has the body of a man but it implements women's features

btw encryption whatever be it, it's not good enough unless it's some public key ( RSA ) encryption scheme ( IPSec ) [ well the session keys i mean being shared by a public key encryption scheme ]

However, since I'm comparing Raknet to TCP, it's not hard at all, since Raknet is already doing it.

well yes raknet seems to implement in 'software' or 'manually' what tcp already provides and that's my point against it : why have software perface culling when the hardware does it automatically? ( yes i know the reasoning behind this, that you get a bit more speed in this case but what i'm saying is that i don't know if it's worth it for cases such as MMOs and not online FPS games. Plus don't forget that probably what TCP has already implemented may be better that what raknet is implementing on its own. )

Off the top of my head: Netrek; XPilot; Navy Field. I won't hold you to a list of 9 though, because it's an irrelevant issue. Any app that uses TCP can be exploited, unless it uses the same technique (encrypted payload) that would protect a UDP app.

Crib notes: I know that it's easy to hijack a TCP connection, because:
1) I have done it, repeatedly, and
2) I am lazy, and wouldn't bother doing it if it were hard.

2) don't believe you, you're always good at pointing out the details and not lazy at all judging by your forum and commits activity

well actually if the app's net game library is strict UDP then all those apps are vulnerable so it's all of them ( unless they're using libraries with custom security features implementations ) so that's more than 9

[rogerborg]

yes but that requires that you have access to the client machine. hijacking the sockets before even hitting the OS assumes that you have admin/root access in the target machine which is not the case we are discussing here

It's one case. You don't always need admin access on (some) Windows machines to hijack system calls; it depends on the DLL search path.

I don't really know what the remote spoofing case is, since it requires you to know the source IP that you're masquerading. How do you get that?

yes exactly you are comparing tcp to raknet which is not fair.

All's fair in love and intartubes wars.

If you know of a TCP library that provides what Raknet provides (multiple independent streams, authentication, encryption) then we can compare them. Until then, since Raknet (Enet, IrrNet etc) actually exist, I can't see how it's unfair to compare the available implementations.

Bear in mind that (e.g.) BSD sockets are just an implementation of TCP/IP. Is it unfair to use BSD sockets or Winsock? Should we be comparing theoretical direct access to the protocol stack?

However, since I'm comparing Raknet to TCP, it's not hard at all, since Raknet is already doing it.

well yes raknet seems to implement in 'software' or 'manually' what tcp already provides and that's my point against it : why have software perface culling when the hardware does it automatically? ( yes i know the reasoning behind this, that you get a bit more speed in this case but what i'm saying is that i don't know if it's worth it for cases such as MMOs and not online FPS games. Plus don't forget that probably what TCP has already implemented may be better that what raknet is implementing on its own. )

I agree that if you absolutely require every byte to arrive, and to arrive in order, and that you don't care how fast you get any given packet, that TCP is a better choice.

TCP is a perfectly viable choice for a MUD (whatever the modern parlance it) because, well, it always has been. The one piece of advice that I would give is to consider making multiple connections per client, so that data that doesn't need to be delivered in sequence can be exchanged over multiple independent streams.

[Mirror]

It's one case. You don't always need admin access on (some) Windows machines to hijack system calls; it depends on the DLL search path.

yeah but once you got whatever kind of access on a windows machine there is no point to even discuss which protocol ( tcp / udp ) is easier to hijack, that's what i meant.

The one piece of advice that I would give is to consider making multiple connections per client, so that data that doesn't need to be delivered in sequence can be exchanged over multiple independent streams.

you mean, like a torrent protocol ? sounds cool but also hard to manage -at least to me - it would be a good idea for example if the game delivers real-time content ( i.e. player constructed parts of the world ). But of course since you can't trust the client, the data would have to pass through a server first for integrity issues etc and then to the other client.

[xsocom]

I agree that if you absolutely require every byte to arrive, and to arrive in order, and that you don't care how fast you get any given packet, that TCP is a better choice.

Ofc I want all to arrive in an online game.

So an fast and easy question, will raknet be a good choice for a Online RPG Game?


Absolutely yes.

TCP is a perfectly viable choice for a MUD.

So raknet is not for me then? because I want all to arrive because its an online RPG game/mud..

[Dorth]

There is not a single feature tcp/ip offers you that RakNet can't do. How's that?

[rogerborg]

I agree that if you absolutely require every byte to arrive, and to arrive in order, and that you don't care how fast you get any given packet, that TCP is a better choice.

Ofc I want all to arrive in an online game.

Urgh, I give up.

[Dark_Kilauea]

Urgh, I give up.

It's ok rogerborg, all he needs is a couple weeks doing game networking.