Reliable UDP

| 6 Comments

I've been doing some work for a client on their reliable UDP implementation. It's been interesting stuff. They had picked out a 'best of breed' open source, reliable UDP protocol implementation (ENet) which was in 'C' and integrated it into their server that was written in C++ with my framework. Unfortunately the 'C' API assumed a synchronous 'pull' model for the communications and The Server Framework gave them an asynchronous 'push' model. They called me in to look at the system and improve the performance.

The work has been interesting and the conversion from the 'C', synchronous API to C++ async has been challenging, but things are nearly complete now and the system seems to run much better than it did before, so I'm happy and they seem happy too. I've done several of these "sync to async" conversions now and I'm getting the hang of it. Async systems are, essentially just big state machines. You push data in and they churn around inside and eventually do stuff and maybe push data out. The OpenSSL asynchronous connector that I wrote was a good starting point, though in that case the library was already quite flexible. In this case we pretty much rewrote the existing library but the resulting code is now much more efficient.

Two things I've realised from all of this are; a) I should investigate a few more reliable UDP implementations as it would be useful to have some options for this built into the framework and b) 'C' sucks... I'm sorry, but, all that declare all the variables at the top of the function stuff is just SO much of a pain when you're trying to write nice clean code...

6 Comments

I hate upfront declarations too, but they haven't been a requirement in C since C99, which is 8 years old now.

Using a crappy C compiler? MSVC? :)

Well, a simple renaming of the files to .cpp or setting compiler options to compile as C++ would have fixed it too. I think the issue was mainly that the C had been 'ported' to C++ without as many changes as there could have been ...

Declaring all variables at the top helps mental discipline. I've seen the misguided declaration of variables midstream in a function in some silly attempt at efficiency. And, it is butt ugly to read.

Ever don PIC declarations in a Data-Section in COBOL? You'd probably have a coronary.

For hardware oriented programming C is a more appropriate tool. Assembler is even better.

Each to his own, but, IMHO, in C++ you're very wrong.

P2engine is a flexible and efficient platform for making p2p system development easier. Reliable UDP, Message Transport , Message Dispatcher, Fast and Safe Signal/Slot...

http://sourceforge.net/projects/p2engine/

And what on earth made you think that spamming my site was a sensible and grown up way of getting traffic to your site?

Leave a comment