Dear 'GameDev.Net' friends, I do work in my off time for almost 6 month on some protocol for gaming and similar useage. I got quite far with it right now and I am thinking about to send it to IANA next year for registering as a public protocol. But since there are always some theoretical problems and possible enhancments that could be made, I was already thinking about sharing information with people working on similar protocols. I had also signed at IETF to a group working on DCCP, which seemed to have a little in common to me from it's focus. But this didn't help it a lot, since DCCP is mainly focused on replacing UDP for some purpose and is not going to get a standard for long time I guess ;-) Going through a number of larger changes at the development of a generic solution for game communication, I had started registering and reading may threads in this forum and found a number of people working at a similar field. Some with a focus at a more like replacement for openTNL/Rakknet, some with a focus to some more lower level protocol replacing UDP. Well, at this moment my focus is neither one of them. The protocol is actually located somewhere between UDP and higher level protocols (openTNL/Rakknet/ect.). Right now the protocol supports from it's specification the following: * any mix of reliable and unreliable data * out of band data transfer * timestamps * roundtrip time estimation * frame to time synchronization * sessions * commands for setting per connection related data * some other features I do not want to explain at this point, because this here would get quite large... ;-) The protocol adds a little overhead of average 2 bytes to UDP. It is not intented to be used with all options at once, but instead by using protocol templates best fitting each games needs. So I do expect that it will be capable of covering a wide range of application types in the field of gaming, since it is more kind of a open framework for frame based communication, than a restrictive way of data transport. So nothing like RTP, that is bound to specific content. In this sense it is not meant to be a replacement for higher level protocol layers such as TNL, Raknet, ect., while it covers some of their included features, since there is no layer for this right now. I'd rate the protocol between such higher level protocol suites and UDP, clearly separating user data from a transport layer and partially covering features, that are, from my little opinion, misplaced at a user protocol level. While still in development it is not expected to be used in the public right now. But this hopefully will change soon... ;-) What I also do not want to do right now, is to put it into a too much public discussion, because from my very expirience such does not help too much with development, but is time consuming and little productive. I actually do look for other people working at similar protocol development with about the same focus, to perhaps put, whenever reasonable(?), work together, preventing the creation of a large number of mostly equal protocols. So I was thinking, if some of you might work on something comparable, perhaps we could take a look if we could share information and perhaps put our work into one? Well, this is just an idea about possible collaboration, but if you are interested, fell free to PM me and we can find out if we are heading the same direction and want to put work together?! - amici summus - p.s. If your work is not intended to be used by the public free of charge and partially or as a whole propriatry we certainly MUST NOT put our work together, since my intention is exactly that ... the protocol is meant to be open to anyone, well described in an RFC, free of charge and designed for a wide range of applications in the field of gaming, telemetry and various types of simulations.