Hi Christian, Thanks for your comprehensive reply.
On 4 April 2011 18:36, Christian Van Brussel <[email protected]> wrote: > For sure, an UDP implementation is more adapted to fast games than TCP. agreed > But an incomplete UDP implementation is as useless as an incomplete TCP > implementation. > > So, there is really no point to provide an UDP alternative to the existing > network layer, if in the end it still remains unused. very good point > > The network layer in CEL has been thought this way: > - 1: design an API abstracting the actual implementation of the network layer > - 2: write a TCP implementation of this API since this is the most easiest > way to do it > - 3: design and implement the property classes needed to define the > network behavior > - 4: implement more advanced solutions for the network layer, eg UDP, P2P, > or based on Raknet, etc a useful explanation. I think this relates to my networking layer / communication layer / entity layer explanation? > > So, we are at step 2 and would like to go to step 3 and 4, not to start > again to steps 1 and 2, or skip to step 4 before step 3. > The goal of a GSOC project about that would be to do step 3 and optionally > start step 4, if and only if step 3 has been completed, but the step 3 is > probably big enough to cover a whole GSOC project. > this makes a lot of sense, i would prefer to produce something that could and would be used easily and intuitively and was polished rather than a framework that was difficult to make use of > > What would be needed for step 3: > - a system so that the whole networking behavior is defined through > property classes: basically, you would have to define eg a property class > for each of the main concepts defined in network.h, ie game/game > client/game server. As a result, a network game should be defined only by > using some specific entities and property classes, and nothing else. This > is not the case for example of CEL/apps/nettest. Understood > > - define for each existing property classes how they update efficiently > to/from the network: this is NOT at all a matter of simply writing or > reading data to a buffer or doing some sort of compression, this job is > already done by the network layer. Instead, the job would be to find an > advanced extrapolation/interpolation scheme for each different property > class. So for example iPcLinearMovement would use dead reckoning, the > physical propclasses would need some complex scheme due to the complexity > of their behavior, etc. yes! I started to try and explain this concept in my proposal but do not go into enough detail. So each property class type is aware of the type of data that it represents, and knows under what conditions it should replicate that data. (dead reckoning, delta threshold, time interval based, etc) > > - the demo recording and loby facilities would still need to be added > > > About ENET, I'm sorry but I don't agree with you :) > This library implements a semi-reliable transmission over UDP. This is of > course achieved by re-sending multiple time a same UDP packet until an > acknowledgment is received. > This is NOT what would be needed for an UDP layer of a networked game > because it would introduce too much latency. An UDP layer should implement > by itself the semi-reliability of the transmission, and that would be its > only difference with a TCP layer. > yes and no. I agree that you are correct about a semi-reliable transmission being useless and introducing too much latency. A feature of ENET you may not be aware of is that pakcets can be sent as Reliable Unsequenced, Reliable and Sequenced, Unreliable and Unsequenced. http://enet.bespin.org/struct__ENetPacket.html When transmitting reliably, it does send multiple times until an acknowledgement is received. When transmitting unreliably, no acknowledgement and resending is implemented by the API. This is the type of communication that would be used for a low latency game and would use Quake 3 style delta compression sending all updates since the last acknowledgement every frame. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking This is a widely respected strategy as it is easy to implement, very robust and high performance. Hope I have managed to change your mind regarding ENET :) But I still agree that UDP is low on the priority list and property classes using the existing library would be a much more significant step forward. > >> Can I ask who would mentor this project? > > Maybe the original author of the network layer would be interested to keep > an eye on it ;) > This would suit me well, the existing code looks tidy and clean and well thought through. Can I ask who this is? Thanks for the feedback. Best wishes, Dan ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
