libaeon Networking LIbrary / News: Recent posts

There has been reports of a runtime issue (stack overflow) at some point in the receive function(s) of libaeon. Updates will come soon, hopefully.

libaeon 0.16.21 is now available in tarball format.
Please update to the latest version, as it fixes some problems with compilation on *nix platforms.

The updates for gcc have been committed to the devel branch in svn. Please use this version until a formal release can be made.

I am in the process of fixing some compile-time issues with the library. It seems that gcc 4.3.2 (and possibly other versions) have an issue with the library and the scope of certain functions. I will post when the issues have been resolved.

The libaeon developers ask for your support. libaeon is desperately in need of someone to donate a Macintosh system, capable of running Mac OSX and possibly MacOS 9, to test development and stable releases. Understandably, we don't expect a top of the line system. Anything capable of simply loading the basic OS, and the ability to compile the library would be suitable. If you happen to have a Mac collecting dust, let us know!

libaeon is in need of 1-2 developers with at least 1 year of c++ experience, preferrably with some experience programming for network sockets.

If you are interested in developing for libaeon, please contact the developers through their sf.net emails, or through the libaeon forums.

libaeon is "An Extensible Open Networking library" that attempts to make full use of std syntax and provides classes for data handling, manipulation, streaming, and inheritance while remaining lightweight, fast, and portable.

Version 0.6.19 brings some small fixes to value returns and MSVC2k5 conformance. Now you may rest assured when compiling against libaeon on Windows OS systems. This brings the support list up to: UNIX/Linux/Windows 2K/XP/Vista. Additionally the pseudo-blocking function ReadUntil() was added to allow developers the ability to force a read of n bytes.

So, I know it's been a long time. I know you're all mad that I didn't fix the windows compilation issues. I know you all wanted to see aeon working right under mingw. I'm sorry. I should have done those things a long time ago. I can't fix that, but I can say that THEY'RE FIXED!

All of the compilation issues in gcc under WIN32 are fixed. Now we're just going to have to test VC2005 compatibility and we should be ready to rock on to the next release.

Today we tested the CServerSocket functionality for possible memory leaks, bugs, and various other anomalies. To do so, we made 550,000 non-concurrent connections to a simple echo server. While the CPU usage did jump dramatically, it was to be expected. No sleep() calls were made in the test for the very reason of testing the libraries ability to handle large amounts of connections and still function.... read more

As we near the end of our initial (read: pre-release) development cycle, releases seem to come more quickly. This release fixes many things since our last release, most notably CServerSocket.

This is the first release we honestly feel is worthy of real world testing. That is to say, it is NOT ready for production use. It is, however, quite ready to be used in porting projects, as the majority of the codebase is frozen barring significant issues. Only a few small "gotchas" remain untamed.... read more

So far client functions are working better than expected. The routines are quite fast, actually, which surprised me. Server routines are...(insert 5 minute rant about sockets) broken. While the server functions are broken, the client functions are working just fine. At this point (0.16.16) we're freezing the CClientSocket class. There may be fixes and additions, but the current methods will remain the way they are (no argument/return changes for the time being). Hopefully CServerSocket will be functioning properly within a few days. CSocketSet should too be working (if it isn't already) soon, as soon as some testing can be done. Let me know if you decide to use libaeon in a program, I can add it to the list.

We're looking for some developers willing to give libaeon a shot. That's right, we want you to include/link to aeon in your devel branch possibly, so that both projects can mutually benefit. The outcome is twofold: Your project will be using a maintained, high quality, cross platform networking library while aeon will be receiving a lot of QA testing and debugging.

Development is going smoothly, and the autotools configuration is pretty much done for the source code. Documentation is coming along nicely, albeit at a slow and steady pace. TCP Server sockets are next up on the list (TCP client sockets are working quite well. Almost enough so to be considered stable.) After TCP sockets are done, UDP sockets are next on the list.

We're now using flawfinder to attempt to help weed out security vulnerabilities before they become a problem by using flawfinder. This is transparent to developers not using flawfinder, as well as all end-user developers. Hopefully we can squash any security related bugs prior to a release.

The SVN repository for libaeon is now populated, and has a "working" copy of the library source code in the devel branch. This is NOT a stable release by any means. When a development branch becomes stable, it will be placed into it's own branch for maintenance and upkeep.

Please feel free to use the facilities here at sourceforge to report bugs and request features. libaeon can't grow without support from those that are using it in both testing and production code.