I suggest against UDP based protocal use. 1 it's unreliable. 2 I wouldn't beable to connect through ssh. Please not UDP, I'm not _That_ worried about bandwidth consumption. I am VERY glad CF uses TCP. --- tchize < tchize at myrealbox.com > wrote: > Blind compression of protocol is a bad idea. > Here is why. > There are mainly 3 parts of protocol which consume > lots of bandwidth and, so > are interresting to compress. > > 1) text messages to player. > When use hit/miss a monster, server send lots of > message telling player how > combat is going. Those message are all in forms like > 'You hit kobold very hard' > Don't forget that is one packet as a whole, so you > need to find a a way to > compress that sentence alone. Try to cut an past it > in a .txt then zip it and > see result (yeah, compressed size is the double, > because you need to send the > compression alphabet used). A bettr way would be, > perhaps to send only to > client the number of the creature being hit (an > int16) along with the > 'template' used for message (could be another > int16). Never investigated a > lot this. > 2) pictures. > Depending on configuration of client, the client may > cache pictures or not, > even could comme with a standard preloaded set of > pictures or could download > the pictures from server at startup. As pictures are > already png, unless you > force client to cache pictures (this prevent sending > pictures each time a > square change in map), you can't gain a lot in this > way. (Preloaded set with > 'on connect' checksum / download seem the best path) > 3) Mapinfo > There are lots of map related info send to client, > when he moves, when he is > looking at the animated sea (each animation is > change in the map and so a map > packet sent). I already analyzed this in the past, > and i concluded, by > running with a quite fast player, in bigworld > (pictures were cached at > connect time and so didn't influence bandwidth use, > statswere at max and > didn't influence bandwidth too, no monsters around), > that the bandwidth use > can sometime rise up to 32K/s just for map datas. > Unfortunately, as is, it's also impossible to > compress that data. These are > already tight binary datas and, when you have > recurrent informations, like > when you have a cyclic sea movement, you can't > gather all them to 'hope' zlib > will compress them. Because you'll have to stack > datas for about 2 seconds > (imagine the lags). > > > Now, am not saying we can't compress datas, just > that we need a better way, > which has already been discussed for about a year on > irc. The idea is mainly > around the mapdatas , but not only. The purpose is > not to reduce bandwidth > (but it indeed reduce bandwidth) but to prevent user > lags. That's what we > need to concentrate on. The suggestion lead to the > following point > > 1) Use an udp based protocol. This prevent the > bandwidth consumption of tcp > packet resend query, tcp stacking and so on, but > this protocol is not > reliable, so we need to add redundancy on critical > datas (we don't mind > loosing a 'you hit kobold' message or a 'sea did > animate' one), but when > player moves, we need to ensure client got the > information. When player > changes map we need to be sure it get this > information too. When players are > chatting also, this must be reliable. > > 2) Because there can be lag between a 'move' command > from client and a > 'mapscroll' answer from server, client need to take > some advance in the > movement. It need to 'suppose' the movement, thought > the server remains the > only controller of the 'can move' logic. This mean > we must send additionnal > datas on which areas are passable and which not. (or > at least 'seems > passable'). > > 3) Because animations on maps are a waste of > bandwith (cyclic animation, like > sea, rivers, lava, snow), we need to tell the client > the animation exists, > the speed of the animation and a timebase to > synchronize it's first frame. > That's a bit more datas but sent only once. > > 4) Because sending additionnal datas for an > animation player will merely see > only half because he just run by when goind > somewhere else and because most > of the envirronement never change (trees remain > trees, grass remains grass, > lava, etc) we should preload to client the maps > backgrounds. > > 5) Because we need to keep all dynamism of current > map system (a grass square > could theorically be changed by weather system. You > could create a map with > scripting where a lever would remove lava, aso) we > need to have a way to > 'patch' the client map when such change occur and a > way to track this. > > All this need to make a list of important datas, of > less likely to change info > on map (should be automatic and based on > is_floor/alive/can_pick tags). > Moreover, this need a redo of current protocol which > would not be compatible > (well technically because we would use udp and not > tcp, we can easily decide > if we use new or old protocol with client). > > So i think this is not as simple as compression, > this is some quite huge work > that need to be done and turn around in my mind for > more than a year. But i > sure hope to see this alive one day or another :) > > > > > Le Lundi 11 Octobre 2004 20:05, Ben Jolitz a écrit : > I think that is an excellent idea. Perhaps using the > zlib compression, > which is standard, you can send more data as > quickly. > I frequently experiance lag on broadband. if Cf > worked on dial up, > think how much better. Perhaps using a system > library, > like libz, is better. But having compressed maps > sent over is really neat. > Ben > > >I was wondering if on-the-fly gzip compression > could > >be added to crossfire, since much of the traffic is > >text based map data. Routienes could be pulled from > >mozilla or midnight commander to implement it. > > > > > > > >Thoughts? (Would speed things up for dialup users). > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > -- > -- > Tchize (David Delbecq) > tchize at myrealbox.com > Public PGP KEY FINGERPRINT: > F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 > C17C > Public PGP KEY location: > http://wwwkeys.pgp.net/pgpnet/wwwkeys.html > > ATTACHMENT part 1.2 application/pgp-signature > _______________________________________________ > crossfire-devel mailing list > crossfire-devel at lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel