Hi,
presenting my C++ library which offers a network layer for TCP server and manages network sockets in separate threads.
libcliser
It has thin area of use but offers simple API.
The library is cross platform, tested to work under linux and Windows. Under Windows it was tested using MinGW compiler, but in theory should work with MSVC compiler too.
Any feedback is welcome.
libcliser: C++ library for creating multithreaded TCP servers
Hi,
presenting my C++ library which offers a network layer for TCP server and manages network sockets in separate threads.
libcliser
It has thin area of use but offers simple API.
The library is cross platform, tested to work under linux and Windows. Under Windows it was tested using MinGW compiler, but in theory should work with MSVC compiler too.
Any feedback is welcome.
Don't take this the wrong way, but I'd like to understand why you made this library, and made it public?
Specifically, I'd like you to answer these questions:
What's wrong with boost::asio?
What's wrong with SDL_net, or plib, or one of a zillion other "portability" network libraries?
Or RakNet, or Enet, or ACE, or ICE, or one of a zillion other higher-level networking libraries?
Why are you serving sockets in separate threads, when that's well known to be inefficient? (see the FAQ)
Your answer may be "because I wanted to learn networking for real," which is a fine motivation, but it's unlikely that someone's learning project can become a solid foundation for a distributed/networked application, so making it a public library seems weird in that case.
Author
Well, I think my library offers simpler API which allows faster start implementing the server logic instead of coping with sockets-shmockets and other stuff... At least that was my intention, to create a library which would hide all the networking layer.
Regarding serving sockets in separate threads... I'm serving a number of sockets in one thread, and there can be several such threads. So, it is not a one socket per one thread. This maybe not the most efficient approach but in my opinion it provides enough efficiency in majority of cases.
Anyway, thanks for the feedback, this is what I made this post for.
Regarding serving sockets in separate threads... I'm serving a number of sockets in one thread, and there can be several such threads. So, it is not a one socket per one thread. This maybe not the most efficient approach but in my opinion it provides enough efficiency in majority of cases.
Anyway, thanks for the feedback, this is what I made this post for.
Well, I think my library offers simpler API which allows faster start implementing the server logic instead of coping with sockets-shmockets and other stuff... At least that was my intention, to create a library which would hide all the networking layer.
So, you still haven't answered the differentiation quesiton.
Why your library, instead of boost::ASIO, or any one of a zillion of other, high performance, robust, networking libraries?
So, you still haven't answered the differentiation quesiton.
Why your library, instead of boost::ASIO, or any one of a zillion of other, high performance, robust, networking libraries?
I'm for being free to work on what you find interesting. One lib that you didn't mention is Poco. If he wants his library to do well though he'll eventually have to answer the questions you've posed. It is a tough space to break into.
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
I've analyzed the source code very shortly.
As it turns out, this is merely a slim layer over another library named ting that does all the actual work. In short, he's posted the equivalent of maybe a week or two of work (assuming he was unfamiliar with Ting and asynchronous design concepts to begin with), which is based on likely months or even years of other people's much more intensive work and knowledge.
As it turns out, this is merely a slim layer over another library named ting that does all the actual work. In short, he's posted the equivalent of maybe a week or two of work (assuming he was unfamiliar with Ting and asynchronous design concepts to begin with), which is based on likely months or even years of other people's much more intensive work and knowledge.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
