PinkyAndThaBrain

Ahh selfies and rare x-radar ... those were the days.

Apparently not having ids made ploss measurements difficult enough to let double packets easily rank as the longest commonly known about exploit in Subspace.

C2S needs no buffering, your client cannot generate the kind of traffic which would warrant it ... obviously it would be a server only thing, and it would only affect people whos connection could not bear the load otherwise. History based compression doesnt always model the data well, for the timestamps and position for instance delta coding will work better ... does that 30% include the IP&UDP headers? BTW will packets finally have individual identifiers in the new protocol? (This doesnt need a lot of extra bits, only packets with identical timestamps need any extra data ... on average it would probably be pretty negligible.)

100 ms is not accaptable? Maybe you should tell the WZ admins to adjust their lag limits then I find it acceptable to add quite a bit of lag to someone's connection if it can shave off even 5% ploss. I would really like to see 60 second window packetloss measurements in WZ for the !lag command, and Im pretty sure some people would rather not I get to see that I know the game is build on illusions, but I dont think fairness should be one of them.

You could use some type of dynamic back off approach, in a busy base battle you could on average acquire quite a few packets with 100ms+ buffering ... and in an optimal packet timestamp and position would make up quite a sizeable part of the total, and would obviously be quite compressible in clustered packets. -*BAD WORD*- even ignoring compression there is always the per packet overhead.

Is there any work being done between PriitK and Grelminar to create a new protocol, to adress some of the outstanding issues? (Most prominently packetloss measurement ... in addition any bandwith saving would be wonderfull of course, aggregate and compress for instance, even in these days zones like WZ still bring the game to its knees.) Just curious if there is still any real movement in SS development.

There are ready made UDP<->HTTP<->UDP tunnelers out there, if you are on broadband at home (or you have a broadband s-*BAD WORD*-) run the end point of one there and point it to the subspace server of your choice (you need to find out which ports continuum uses ... used to be that the port in zone.dat was the port it used to connect, and add 1 for the port it uses to ping the server and check player count). On the local end run the client part of the tunnel add a new server to zone.dat with IP 127.0.0.1 and the ports you chose for the local side of the tunnel for the given subspace server. Easier said than done though, you really need to have some grip on whats going on to get this kind of thing up and running. Or if you dont mind spending money you could pay for a HTTP-tunnel subscription, which has a local SOCKS5 interface ... dunno how good their servers are though. Alternatively you can buy socks2http and a personal gateway.

If Wick told me it was a stupid idea Id buy it, but if you havent experimented in the field an unfounded opinion is simply that. Arrogance wont give the opinion any more weight for me.

It is not a trivial excercise, you would also need to code a server which handled subspace physics.

No, you would need to code a new client and server. Or you could hack subspace physics into a top-down view mod for a FPS (most FPSs are mostly server authorative, with HL being a prominent exception).

It makes the game unplayable with high lag, but how well would it do in Subspace with say league lag limits? (With a redundancy scheme for C2S communication, say a simular tripple redundancy as Quake had.) Has anyone experimented with this?

Which is exactly my arguement Everything can be broken, so wether giving up a little security is worth it is entirely a matter of opinion. Keeping the security code back and only having it compiled into official clients still provides security. It does not allow players to do anything, it does not allow players to modify any part of their client (at least not the ones they can play with on official servers) and it in and of itself does not allow them to load code into Continuum memory space to observe how the security mechanisms work (since the security mechanisms arent there to observe). It just makes the security code a little easier to isolate in official clients. You can offset that by updating the client more often. Oh BTW, it took me all of 2 hours to load code into the Continuum memory space ... and I am a sucky coder. Security by obscurity might work, but security by blind faith in the inability of others doesnt.

Be that as it may, releasing the source code without the security library != releasing the source code plus security library. Do you really think I would forget other forms of security, given that I already suggested using class based types for sensitive variables to provide a way to easily abstract the security mechanisms earlier in the discussion?

What I am saying is not "Why don't we do X!" it is "Why don't we do !X". You do not say the situation I propose is bad. Not true for the situation I propose. Not true for clients compiled with the closed security code, what goes into those clients is at the complete discretion of the central developers. I can see no reasonable way in which you can construe that I am suggesting this be done.

I have no idea what you mean by perfect physics But you couldnt do anything with the client source code (on an official server) without hacking the encryption and security mechanisms, so point 1 isnt really distinct from point 2. Just a potential consequence. IMO the major problem with hacked clients has been obviousness. As long as there is no obvious cheating there is no problem. I mean you have to be naive to assume that noone is abusing the kind of packet cheats which have been possible for 7+ years (some by abusing inherent limitations placed on the game by being client authorative and because it has to allow some lag, some by design flaws in the protocol which were never fixed). The complete conviction of cheating going on has had an effect on my priorities ... Id rather have the client develop faster than more obscurity. If you put in memory patching abilities in the security code you should be able to combat any blatant cheaters at very short notice without needing to update the client (nearly impossible to sand box something like that).