PinkyAndThaBrain Posted February 12, 2004 Report Posted February 12, 2004 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.
Mr Ekted Posted February 12, 2004 Report Posted February 12, 2004 There was some discussion between Priit and grel about minimizing the position packets (which cons!@#$%^&*ute the majority of the bandwidth). They contain a number of unused bits, or things can could be done differently. Compression is pretty much not possible. It would be rare to find a packet that would be smaller compressed than raw, and you can't wait and buffer up large enough blocks of packets to make compression useful because smooth gameplay relies on packets flowing smoothly.
Trained Posted February 12, 2004 Report Posted February 12, 2004 Ekted, will you help them out at all? i mean, you did help priit with continuum didnt you?
Mr Ekted Posted February 12, 2004 Report Posted February 12, 2004 Priit and I defined an interface between the game and the menu, and we each coded to that interface. We don't have to see each others' code, or agree on a coding style. As far as helping people: I'm not interested in collaboration at this point, but I always try to answer technical questions posted here. As you all know, I am less tolerant of people who do not seem to know what they are talking about. I don't like wasting my time helping someone make "a new SS client of the day" when it's clear they don't even have what I call "Level One Knowledge" of programming. Many people I know who have BS in Comp Sci do not have L1K.
Yupa Posted February 12, 2004 Report Posted February 12, 2004 Hey Ekted, can I have a copy of the source? I'd like to develop it. I want to add a 3D engine and enable virtual reality and make it so when you enter a zone, you are actually taken into the computer - like that cartoon.
Mr Ekted Posted February 12, 2004 Report Posted February 12, 2004 There are 3 kinds of people who would make that post Akai: 1. They are serious. I flame them. 2. They are making a huge joke. I hope you are this one. 3. They are trying to be insulting under the guise of making a joke. I flame them.
Jason Posted February 12, 2004 Report Posted February 12, 2004 Reboot kicked some serious -*BAD WORD*-. It was done with sad looking 3D rendering, but at the time the technology used was cutting edge and I was all, "HOLY -*BAD WORD*- BATMAN!" As a matter of fact, I have every episode on one of these harddrives I have lying around. :] As far as L1K, I'd venture to say I'm at roughly L0.01K, maybe you could slide the decimal to the right one place. Still, it's fun as -*BAD WORD*- using small SS development projects as a means of expanding my programming horizons.
Mr Ekted Posted February 12, 2004 Report Posted February 12, 2004 SS is a great way to learn all sorts of programming aspects: networking, graphics, sound, UI, large data structures, encryption, compression, maybe some DB. Lots to chew on at all levels.
numpf Posted February 12, 2004 Report Posted February 12, 2004 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.Yes, they have communicated quite a bit about saving bits and restructuring individual packets and the protocol at large. Priitk has an actual interest in this because he pays for hosting and believes he could save lots of money with some appropriate changes. Unfortunately it has to wait for ASSS to be tested and implemented. I'm not entirely sure where they are with testing. Once ASSS is adopted though I'm sure that's one of, if not the, first thing they'll look at changing. Packetloss and latency are measured by the server. I believe grel tracks packets much more comprehensively than subgame does, and with ASSS you'll be able to get much more information than ?lag shows you now. edit: Actually the client does most of this. There are some things the server could do to better report it though. -numpf
madhaha Posted February 12, 2004 Report Posted February 12, 2004 I thougth continuum already used a different protocol to subspace, as in different enough to stop snrrrubspace from working properly...
Mr Ekted Posted February 12, 2004 Report Posted February 12, 2004 Continuum uses the same packet structure (with maybe one exception) but encrypts them much differently. Also, there are several Continuum-specific packets that VIE clients ignore.
numpf Posted February 12, 2004 Report Posted February 12, 2004 cont uses a different encryption, which until duplicated (difficult), no client can login and be treated as a cont client. Priitk has _added_ a few packets to the protocol, and I believe added a checksum to every packet, but there's been no serious restructuring of the packets themselves that I know of, because modifying subgame to allow for that would probably be more work than writing a server. His modifications to subgame so far have been mainly additions... what we're talking about would be a massive restructuring, which is very different. Just makes more sense to wait for ASSS.
PinkyAndThaBrain Posted February 12, 2004 Author Report Posted February 12, 2004 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.
numpf Posted February 12, 2004 Report Posted February 12, 2004 they've fleshed it out in much more detail. Holding a packet at the server for 100ms would introduce ridiculous latency. 10-20ms is about the limit. It's unlikely compression would yield much reduction in the average cluster once priitk cuts out the unused bits in pos pkts.
PinkyAndThaBrain Posted February 12, 2004 Author Report Posted February 12, 2004 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.
Grelminar Posted February 12, 2004 Report Posted February 12, 2004 Re: lag measurement. This is pretty hard, and requires cooperation between the client and server, especially because most of the traffic is in unreliable packets. Currently, cont does some work, and ASSS does a little more, but I didn't put that much effort into lag measurement in ASSS (yet). I just got it "good enough" to figure out some averaged ping and ploss values, and then spent more time on penalties you can enforce based on those numbers. There's room for more work there, but to make it much better, I'd need cont to measure and report more detail than it does now.
Grelminar Posted February 12, 2004 Report Posted February 12, 2004 Re: new protocol features. I've come up with some, mainly new game features, and suggested them to Priit. I don't think any of the significant ones have been implemented in cont yet. He's also suggested some, mainly bandwidth reduction things. I haven't implemented these yet, primarily because there wasn't a good way of evaluating the benefit of any new scheme that we might come up with. Since then, I've written some load generating programs, and added some more measurement stuff to ASSS. I'll need to write some more measurement stuff, so I can get a better idea of typical traffic, and then implementing and evaluating some of these ideas will be possible.
Mr Ekted Posted February 13, 2004 Report Posted February 13, 2004 Say you latency to the zone is 50ms, and the latency from the zone to another player is 50ms. So when you move and shoot, the delay from you to them is 100ms. If your client buffered and encrypted packets for 100ms, and the server did the same, then your info would reach the other player in 300ms. I wouldn't play with that kind of lag. Also, how much data does a client send the server in 100ms? About one packet, unless you are in a zone with fast weapons, where it could be 10 or more, but this is unusual. So buffering one or maybe two packets (almost 0% compression) isn't worth the delay. Note, if you ac-*BAD WORD*-ulate and compress large chunks of SS protocol data at a time (say blocks of 8K+), it saves about 30%.
PinkyAndThaBrain Posted February 13, 2004 Author Report Posted February 13, 2004 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.)
Mr Ekted Posted February 13, 2004 Report Posted February 13, 2004 The 30% is data only. You don't really want to id or sequence non-reliable packets. That's the whole point. If you need to know that kind of info, you need to make them reliable.
numpf Posted February 13, 2004 Report Posted February 13, 2004 Note, if you ac-*BAD WORD*-ulate and compress large chunks of SS protocol data at a time (say blocks of 8K+), it saves about 30%.Of course the max packet size is 520 bytes, and the average cluster you could make would likely be significantly less than that. And Priitk plans to change the pos pkt to remove unused bits. -numpf
Mr Ekted Posted February 13, 2004 Report Posted February 13, 2004 Current max packet size is a choice, not a limit.
numpf Posted February 13, 2004 Report Posted February 13, 2004 current max packet size is set because it's safely under the lowest MTU for a modem. You can detect MTU size over a route (and since routes can change MTU can change), but the best you can hope for is under 1.5KB, as that's Ethernet's MTU. I wouldn't start going beyond 520 until lots of statistics were gathered on typical MTU changes between players and the server. -numpf
Recommended Posts