Networking class similar to dlib::linker

[SalvorHardin]

I'd love to see a network class similar to dlib::linker. It would allow me to use Poco for networking (in addition to Poco's wonderful threading framework.)

"This object represents something that takes two connections and lets them talk to each other. ie. any incoming data from one connection is passed unaltered to the other and vice versa."

A server using this would make it easy to connect two computers when both are behind NAT/firewall.

http://dlib.net/network.html
http://dlib.net/dlib/linker/linker_kernel_1.h.html

[aderouineau]

POCO already has a networking library...

[SalvorHardin]

I'm sorry, I should rephrase my wish:

Please add a class similar to dlib::linker to Poco's existing network framework.

This would allow me to exclusively use Poco's network framework, rather than using both dlib and Poco for networking in the same project.

dlib::linker allows 2 connections to be linked together, (e.g. a server can link 2 desktop connections, allowing both desktops be connected to each other.)

Another example is zeromq's "forwarder", which is described here:

http://nichol.as/zeromq-an-introduction

Both linker and forwarder is helpful when you want two machines to connect to each other via intermediary (e.g. two corporate PC's behind NAT/firewall in 2 different locations connecting to each other via server running linker/forwarder.)

I know HTTP proxies are abundant, but sometimes, HTTP isn't the right protocol. A linker or forwarder would allow any protocol over TCP.

ps

I can't use zeromq because of LGPL license.

[aderouineau]

Well I doubt it'd be in the priority list, because you can achieve that functionality by using POCO's networking library...

What's wrong with using dlib::linker ?

[SalvorHardin]

Nothing's wrong with dlib, I just got Poco approved for use at work. And it can be a pain to get open source libraries approved if the "who's using project xyz" page is missing or bad ...

Having said that, "who's using poco" and slides made it 10x easier than other libraries. Plus, the comments about Poco at stackoverflow, etc. have been very positive.

[aderouineau]

And if you're already allowed to use dlib, I don't see the problem of mixing both.

People manage to mix POCO and parts of Boost, and I'm pretty sure it's the hardest combination since they overlap on different areas.

[guenter]

POCO provides all the necessary building blocks for creating something similar to dlib::linker. If you use the TCPServer framework, an implementation is straightforward, although not very scalable. Using the SocketReactor would probably be better. The EchoServer sample should give you something to start from.
A concrete implementation of dlib::linker in POCO would probably be a bit too specific for POCO.

[SalvorHardin]

I've been using SocketReactor to build a demo/prototype and it is really nice. Especially when used with NotificationQueue.

But, it seems I incorrectly assumed TCPServer would be more scalable than SocketReactor, because SocketReactor uses 1 thread for all connections.

A few more words about scalability difference between TCPServer and SocketReactor (on server-side) in the Network PDF slides would be fantastic. But as someone who hates writing docs, I greatly appreciate all the docs already available!

[aderouineau]

SocketReactor is not necessarily more scalable than TCPServer. It really depends on how each connection is treated compared to the rest: if there's a lot of shared data, a reactor will definitely be better whereas if each connection is pretty independent, then a thread pool would most likely be more appropriate (as long as there are multiple cores of course).