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).

You dont need to give out the security library at ALL. If you can find client developers who are a little less up tight about open source development and are willing to accept patches all you need to do to allow third party contribution to the client is to release the source code with a nullsecurity.lib/a for instance. This would remove the security mechanisms and only allow you to play on servers which have you in their VIP list, just like open source bots. Audited patches deemed worthy could go into the client. The only clients which could play on the real server would be the ones compiled with realsecurity.lib/a by the central developers for instance. (Personally I would do it with class libraries ... using classes with operator overloading as types for sensitive variables would allow a much nicer abstraction of data protection mechanisms.)

For someone who would refuse to accept patches anyway open source makes little sense, such as Mr Ekted. In general for hypothetical alternative projects you could open source all the non secure parts and distribute them with a dummy security library which would only let you play on your own server (or servers which put you in their VIP list). This would be the closest equivalent of how ASSS opens the server source. While ASSS can get away with merely close sourcing the security code because the server is not under player control anyway, since the client is the final linking with the security code into a usable client (for official servers) would always have to be done by a central authority.

None for clients which can play on the official servers. Not ... it is not needed for development of non-secure parts of the client. You can connect to your own server without encryption. If they did the same thing PriitK did they wouldnt need any zone to start using it as such. That is a political issue ... if things go on as they have I dont think it impossible for a new client to be embraced again. Happened before, can happen again.

That is unnecesarily adversarial. Mr Ekted seems like a reasonable person, whatever you think about his knowledge, and PriitK seems like a person who doesnt care one way or the other what anyone else does. I doubt Mr Ekted likes Grelminar's choice of development model for ASSS but he supports it nonetheless. Pretty silly to talk about copyrights, neither Mr. Ekted or PriitK have ever !@#$%^&*erted inherent rights to dominance of development of Subspace ... their right comes simply from standing up and providing Continuum, if you or anyone else wants to better them just do so (-*BAD WORD*- Im sure if you produced a credible project you could even get a forum on here, seeing that someone like Polix mostly agrees with you). College students tend to have a lot of time on their hand, all you need is a decent coder with lots of time on their hands and some determination ... About the necessity of single coders, you always need a single coder to get projects started ... but this isnt rocket science for God's sake. The Linux kernel IS a lot more complex and fragile than a friggin 2D multiplayer game engine, and it seems to manage just fine with its development model.

Get as many freshman college students addicted to subspace as you can (preferably EE students) and hope for a miracle.

Carmack has put back doors in his code and is entirely unapologetic about it ... I see really no reason to trust PriitK and Ekted more than some mod author, I know neither. If someone put a lot of time into making a good enough mod to get a trustworthy server operator to run it then Ill have as much faith in the mod as in Continuum (which is to say not a whole lot, but in general I dont care about security much). Unreal engine games are very nice examples of scripted games BTW. To turn Subspace into something like that would require a complete rewrite though. Personally I like how ASSS does it, abstract the protection mechanisms and open source the rest... the client is a little different in that you couldnt distribute the protection mechanisms themselves. For development of the client you could include a library for simple unencrypted traffic and all integrity checks would just be empty functions (you could only test on your own server where you would specifically allow those clients to connect). The final authority for code going into Continuum would remain where it has always been.