Split library itself and sockets io

LibVNC / libvncserver

LibVNCServer/LibVNCClient are cross-platform C libraries that allow you to easily implement VNC server or client functionality in your program.

GNU General Public License v2.0

1.14k stars 494 forks source link

Split library itself and sockets io #432

Open efimbushmanov opened 4 years ago

efimbushmanov commented 4 years ago

Now, its impossible to use libvncserver for heavy load projects, cloud based project and etc because of private, internal usage of sockets. There is little begining for this like support of inetd (external) sockets.

I want to add some system or option to bypass integrated private sockets communication and add external implementations for sockets calls like select/read/write/close.

Make interception of read/write/close calls on LD_PRELOAD its not good solution, imho.

Same question was raised previously regarding tls implementation.

Its can be found here: https://github.com/LibVNC/libvncserver/commit/b7d57ea2bd94fb901a660bb68d041c27d9e349c9

But my opinion, tls should be implemented in some other way, not with read/wrete overload. Maybe just like in libvncclient case.

Related pull request with more comments and possible solution for remove close calls and impementation of external_sockets flag: https://github.com/LibVNC/libvncserver/pull/428

efimbushmanov commented 3 years ago

Also, it may be very useful for bandwidth management. Where you can control bandwidth usage per client. For that, better implementation will be add fully functional so called "transport" [middle] layer between application data and socket system.

Like it was already implementing in freerdp, for example.

https://github.com/FreeRDP/FreeRDP/pull/6455/files https://github.com/FreeRDP/FreeRDP/pull/6455

I think, its better idea, than use some flag in settings and adding many "if"-s conditions. It also, may be good start for adding TLS-layer support later almost automatically.

efimbushmanov commented 3 years ago

@bk138

bk138 commented 3 years ago

Thanks for the ping. So here's the current situation:

I'm quite busy with $$$-work and family these days.
I'm personally not in a desperate need of a feature like this but of course YMMV and that is perfectly OK and valid.
That being said, I'll not be able to spend a lot of thought and time on this, but I am willing to set aside some time to review designs and code and eventually merge stuff. It's just that I'm not able to actually work on this.

So much for setting expectations :-)

As for your link to freerdp: it's probably very wise (or just efficient) not to reinvent the wheel on our own but instead do it like others have done it before. So yes, a transport abstractions is viable. I still feel that #396 could be squared away with something like this as well.

efimbushmanov commented 3 years ago

Thanks for the reply! Of course, its up to me for implementing this. I will start working on it with care, to be sure to fit main concept goal.