Which C++/C Socket library should I use for the project?

[Michael Prinzinger]

Dear Phantoms!

To proceed with the project according to plan, we will need TCP Socket functionality.
I tried for a while to write some abstraction from the berkeley socket C API myself, but I realized that this takes a lot more work than expected.
So I have come to the conclusion that it is better to include a well developed well maintained abstracted C++ library instead.
Thus the decision must be made which library to use, and I'd like you to help me there. Maybe you have used one before and can tell if its great or horrible, or maybe you have some knowledge about a popular library people who have never used it don't.

So here's a list of libraries, which appear useful to me:


QT Network Module
http://doc.qtsoftware.com/4.5/qtnetwork.html

Pro: QT is very well developed, documented and maintained, cross platform compatible and provides SSL functionality for Sockets (between socket connections)
Contra:QT is very big and might be overkill if we only use the network module, the SSL functionality only allows to encrypt connections, not to encrypt i.e. the setup package (Goodie Box)

Boost Asio
http://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio.html
http://alexott.blogspot.com/2007/10/what-is-boostasio-and-why-we-should-use.html

Pro: seems to be "the internets" favorite Sockets library, cross platform, SSL functionality (e.g. used in libtorrent), documentation and examples, scalable and efficient
Contra: Boost is also very big and might provide too much, only basic SSL functionality for encrypting tcp-streams, we would still need to use OpenSSL (or TLS) directly for e.g. encrypting the GoodieBox

POCO
http://pocoproject.org/

Pro: constructed as an extension to STL (very good interoperability), cross-platform, provides encryption (NetSSL)
Contra: same as above: very big library (more than we need), SSL only for streams

ACE (Adaptive Communication Environment)
http://www.cs.wustl.edu/~schmidt/ACE.html

Pro: cross platform, very popular, good documentation (including books)
Contra: again very big

A light-weighted client/server socket class in C++
http://www.codeproject.com/KB/IP/client_server_socket.aspx

Pro: very small (no unecessary stuff), very generic (flexibility)
Contra: almost no documentation, community, maintenance, no SSL functionality for streams

C++ Sockets Library
http://www.alhem.net/Sockets/index.html

Pro: unixes (incl. mac and solaris) and win32, SSL support, reasonable size, documentation, tutorials and examples
Contra: SSL only for streams


The choice is quite hard. I tend to one of the top ones, because they are easy to learn&use and take a lot of trouble away from the programmer. (also because I have limited time for finsihing my thesis).
However I see Magnus' main criticism, that this might violate the design goal to keep Phantom small and specialized, since we would include a lot of functionality we don't need.

So please help me make that decision for the project.
And please answer as quickly as possible, because of my limited time span ;)

Thank You!

Michael

[Michael]

Hey all!

I was a bit frustrated with sockets, when writing the previous mail.
I tried again to work with the C-Berkely Socket-API and found it's not
as difficult as I thought.
So I guess working directly with it, it is the best way to go after
all.

Alright, I'll keep you informed!

michael

On Jun 23, 3:26 pm, Michael Prinzinger <tay...@gmail.com> wrote:
> Dear Phantoms!
>
> To proceed with the project according to plan, we will need TCP Socket
> functionality.
> I tried for a while to write some abstraction from the berkeley socket C API
> myself, but I realized that this takes a lot more work than expected.
> So I have come to the conclusion that it is better to include a well
> developed well maintained abstracted C++ library instead.
> Thus the decision must be made which library to use, and I'd like you to
> help me there. Maybe you have used one before and can tell if its great or
> horrible, or maybe you have some knowledge about a popular library people
> who have never used it don't.
>
> So here's a list of libraries, which appear useful to me:
>

> QT Network Modulehttp://doc.qtsoftware.com/4.5/qtnetwork.html

>
> Pro: QT is very well developed, documented and maintained, cross platform
> compatible and provides SSL functionality for Sockets (between socket
> connections)
> Contra:QT is very big and might be overkill if we only use the network
> module, the SSL functionality only allows to encrypt connections, not to
> encrypt i.e. the setup package (Goodie Box)
>

> Boost Asiohttp://www.boost.org/doc/libs/1_36_0/doc/html/boost_asio.htmlhttp://alexott.blogspot.com/2007/10/what-is-boostasio-and-why-we-shou...

>
> Pro: seems to be "the internets" favorite Sockets library, cross platform,
> SSL functionality (e.g. used in libtorrent), documentation and examples,
> scalable and efficient
> Contra: Boost is also very big and might provide too much, only basic SSL
> functionality for encrypting tcp-streams, we would still need to use OpenSSL
> (or TLS) directly for e.g. encrypting the GoodieBox
>

> POCOhttp://pocoproject.org/

>
> Pro: constructed as an extension to STL (very good interoperability),
> cross-platform, provides encryption (NetSSL)
> Contra: same as above: very big library (more than we need), SSL only for
> streams
>

> ACE (Adaptive Communication Environment)http://www.cs.wustl.edu/~schmidt/ACE.html<http://www.cs.wustl.edu/%7Eschmidt/ACE.html>

>
> Pro: cross platform, very popular, good documentation (including books)
> Contra: again very big
>

> A light-weighted client/server socket class in C++http://www.codeproject.com/KB/IP/client_server_socket.aspx

>
> Pro: very small (no unecessary stuff), very generic (flexibility)
> Contra: almost no documentation, community, maintenance, no SSL
> functionality for streams
>

> C++ Sockets Libraryhttp://www.alhem.net/Sockets/index.html

[Leslie P. Polzer]

On Jun 29, 4:39 pm, Michael <tay...@gmail.com> wrote:

> I was a bit frustrated with sockets, when writing the previous mail.
> I tried again to work with the C-Berkely Socket-API and found it's not
> as difficult as I thought.
> So I guess working directly with it, it is the best way to go after
> all.

FWIW we have decided to use OpenSSL's socket abstractions.

It's a proven and portable system that's both simple and extensible
and relies on a library we need to use anyway.

[Magnus Bråding]

Hi,

Sounds like a very good choice!

Regards,
Magnus

[defenderh2o]

hi

i did see that here on my First XP with SP3 tested RetroShare as local
version,
it goes DHT and NAT ok
and see on Network Status more green too.

Only on my XP SP2 there works upnp which goes the light on, seems upnp
doesnt like
XP SP3.