Modem Tapping?

[Lance]

Originally Posted by Kaimetsu

Movement packets are actually UDP datagrams, right? From what I understand of the protocol, it's a very fire-and-forget system. If the client tries to send them when the connection is down, they'll just fail and be forgotten. They don't enter any kind of queue, so it's not like the server will be receiving more than usual once the connection is reestablished.

I do not deny my ignorance of such protocols, but TCP is another option for Graal, and I do believe that TCP operates differently. If these packets were just ignored, then how would you explain this:

I've seen an individual player stop moving for some arbitrary length of time and then seen them start to move again, only they are moving faster than is possible along the paths they presumably walked along while they did not appear to move.

Why tackle a single cause and not the problem?

The problem here is that players can move in ways that weren't intended. That is the problem. Your advised approach is like saying we should ban cigarettes so we don't have to bother looking for a cancer cure anymore.

I still don't agree with your naming conventions here. I don't see the unintended movement as a problem of its own to address (like cancer is) but more as the visible effect of some other problems, much like a fever that is a symptom of some bacterial infection. Sure, you can take something to deal with the fever, but would it not be far more productive if you took something to deal with the bacteria? Sure, you can do both in this example, but I hardly think it's a good (or, better, as I initially inquired) idea to just treat the fever.

I just see a lot of problems with monitoring the player's actual speed. It just gets too complicated. What about servers that allow you to move quickly, staff boots, vehicles that allow you to move faster than you walk, etc.? Where do you draw the line? For example, if you don't let anyone move faster than, say, the trains on Graal2001, that's fast enough to render it relatively ineffective. Sure, the extreme moving-around would be limited, but you could still go as fast as a train.

Would it not currently be possible to send arbitrary movement packets? As long as I don't send too many of them, I can move as quickly as I want. I can warp randomly around the level as long as I don't exceed x packets per second.

If you had a method of sending such packets, could you not also use that method to cause some other trouble not related to movement? Then, would not the best method to deal with that problem be to remove the vulnerability that allows you to send such packets, rather than simply dealing with the movement packets you send?

[JudgeDurst]

Couldn't the server (when detecting a possible speed hack) clear the stacked data for projectiles etc and warp the player back to their location before this "lag spike" and possibly set back flags?

Now I read my own text I guess some of that probably wouldn't work x.x

[Kaimetsu]

Originally Posted by Lance

TCP is another option for Graal, and I do believe that TCP operates differently

Agreed. But only a minority of users are foolish enough to use TCP when UDP is a viable option.

Either way, operating the safeguard based on actual speed rather than packet frequency would solve the problem in both cases.

I've seen an individual player stop moving for some arbitrary length of time and then seen them start to move again, only they are moving faster than is possible

How does this suggest that undeliverable UDP datagrams are queued on the client computer? I would sooner think that all the player's movement packets have been sent, but traffic conditions force them into clumps somewhere between the player's client sending them, and you receiving the relays from the server.

I don't see the unintended movement as a problem of its own to address

Then perhaps we disagree on the definition of 'problem'. Clearly the movement is the part to which we object; it is the part that causes conflict with other users, grants unfair advantages, etc. It is the thing we want to stop.

I just see a lot of problems with monitoring the player's actual speed. It just gets too complicated. What about servers that allow you to move quickly, staff boots, vehicles that allow you to move faster than you walk, etc

Yes, I had considered this. It's quite a shame that we're not able to interact more directly with the gserver's code. It would be nice if we could completely redefine how the server reacts to each packet of information, according to various scripted conditions. The server knows if the character is on a vehicle, for example. In such a case, it should ignore all movement packets and let the NPC move the character.

Maximum speed would then be configurable per player, per situation, nullifying your objections.

If you had a method of sending such packets, could you not also use that method to cause some other trouble not related to movement?

Such as?

Then, would not the best method to deal with that problem be to remove the vulnerability that allows you to send such packets

What vulnerability? The only requirement is an internet connection and an understanding of Graal's protocols.

[Lance]

Originally Posted by Kaimetsu

Agreed. But only a minority of users are foolish enough to use TCP when UDP is a viable option.

It isn't a viable option for everyone, though. Some people are stuck behind routers and cannot set up port forwarding for those UDP packets. Other problems may exist, too. For example, when Nappa still used 56k, UDP was not working properly for him. Whenever he had Graal set to use UDP, it was horribly laggy. However, when setting it to use TCP, he did not have that problem.

Either way, operating the safeguard based on actual speed rather than packet frequency would solve the problem in both cases.

The movement would be removed, sure. However, I already mentioned the problems with basing the safeguard on the actual speed.

How does this suggest that undeliverable UDP datagrams are queued on the client computer? I would sooner think that all the player's movement packets have been sent, but traffic conditions force them into clumps somewhere between the player's client sending them, and you receiving the relays from the server.

I did not suggest that the undeliverable UDP datagrams were queued there. I was asking if the TCP option would allow for such a queur or if there was any other possible explanation for that behavior.

Then perhaps we disagree on the definition of 'problem'. Clearly the movement is the part to which we object; it is the part that causes conflict with other users, grants unfair advantages, etc. It is the thing we want to stop.

I'll attempt to clarify: Yes, the movement is a problem. However, I see it more as a symptom of another, perhaps more important problem (or problems) which need to be addressed.

Yes, I had considered this. It's quite a shame that we're not able to interact more directly with the gserver's code. It would be nice if we could completely redefine how the server reacts to each packet of information, according to various scripted conditions. The server knows if the character is on a vehicle, for example. In such a case, it should ignore all movement packets and let the NPC move the character.

Maximum speed would then be configurable per player, per situation, nullifying your objections.

It certainly would be nice, yes. Unfortunately, such is not the case, so it remains unfeasible.

Such as?

Pretty much anything the client can do, such as setting ganis, setting clothes properties, firing weapons, or sending triggeractions.

A question occurred to me: If you sent such a packet that told the server you moved somewhere else, would it display this movement on your screen?

What vulnerability? The only requirement is an internet connection and an understanding of Graal's protocols.

My apologies; I chose a poor word there. 'Oversight' would be more appropriate.

[Splke]

My Brain ;____;

[Nappa]

Yes, when I was on 56k UDP wouldn't allow me to properly play. The lag was so horrible I couldn't even properly move (on GK).

[syltburk]

They always come up with new stuff, dont they?

[Spark910]

Originally Posted by Projectshifter

You're kidding me... people actually pull out their modem cable?

Lol, it's common on online games for consoles. Although I didn't know it was called that, but infact I call it ''pulling the cord'', it has great effect on games such as shooting ones that require you to breach a base for example, as if someone pulls their cord they can breach the base, kill a few people and avoid mines/guards in about 1second when the lag catches up. (Although it may sound like it, I don't do it - that's just the effect is has )

Hell, there is a device made that has a switch on your ethernet cord so you can do it while you play without having to pull it directly out of your modem/router. You can make it at home for little, or pay some random joe to make it for you (As most young kids opt for )

[HoudiniMan]

Originally Posted by Spark910

Hell, there is a device made that has a switch on your ethernet cord so you can do it while you play without having to pull it directly out of your modem/router. You can make it at home for little, or pay some random joe to make it for you (As most young kids opt for )

I'll sell anybody who wants one a box you simply clip on to your ethernet cord.

Push the button and it pushes a razor blade down, "interrupting" your connection "temporarily".

(until you get a new cord )

[Nappa]

What if we are wireless ?

[Splke]

Originally Posted by Nappa

What if we are wireless ?

Hopeless, and pointless.

[Skyld]

Walk out of range of your access point, and then wander back in as if you never lost the connection.

[Nappa]

Originally Posted by Splke

Hopeless, and pointless.

A matter of opinion.

[Zero Hour]

Originally Posted by Skyld

Walk out of range of your access point, and then wander back in as if you never lost the connection.

Wow, you really know how to preserve energy.

Originally Posted by Spark910

Hell, there is a device made that has a switch on your ethernet cord so you can do it while you play without having to pull it directly out of your modem/router. You can make it at home for little, or pay some random joe to make it for you (As most young kids opt for )

I will make and sell these to anyone who is interested for a quite unreasonable price.




Seriously.

[Kaimetsu]

Originally Posted by Lance

It isn't a viable option for everyone, though. Some people are stuck behind routers and cannot set up port forwarding for those UDP packets

Yes. But these are a minority.

The movement would be removed, sure. However, I already mentioned the problems with basing the safeguard on the actual speed

And I already responded thereto :-p

I'll attempt to clarify: Yes, the movement is a problem. However, I see it more as a symptom of another, perhaps more important problem

Which is what? Disconnected cables, high-frequency packets? How are either of these, in themselves, problems?

It certainly would be nice, yes. Unfortunately, such is not the case, so it remains unfeasible

Such could be the case. We both know that the best way to get Stefan to add something awesome is to find something that appeals to him and show him that it requires your suggestion to be added

Pretty much anything the client can do, such as setting ganis, setting clothes properties, firing weapons, or sending triggeractions

Mostly not too big a deal, as long as the server does some simple checking.

A question occurred to me: If you sent such a packet that told the server you moved somewhere else, would it display this movement on your screen?

I don't know exactly how Graal works, internally. But a suitably skilled user could always edit his client such that it does.

My apologies; I chose a poor word there. 'Oversight' would be more appropriate.

Well, it is still not something that you can simply "remove".