Add option to send data over a tcp socket

[LinusCDE]

Hi,

here is the PR with for creating the tcp tunnel which was the one you seemed most interested in.

I have to agree that the FPS cap is probably not worth, since people who can't see the fps could not make use of the even then limited usefulness (maybe an update to e.g. embed an optional fps counter in the framebuffer in the future?). The monow thing seems to be unstable as well (I guess more because of the lz compression, the seperate performance-mode branch I had without lz4 worked well. Does not seem to be because of the unsafe part but that is also less than ideal. Maybe there is a better way to achieve the goal with some library).

If you want any changes let me know. I also might take a shot at xoring the framebuffer for performance gain. Though keep in mind that one probably needs to decrease the lz4 block size as I did in my monow commit on feature/stuff since the framebuffer gets very small and delays the frames a long time as a result.

[LinusCDE]

Also note that this currently uses netcat (nc) to receive the unencrypted framebuffer. Not sure how the story goes on windows with that. I'm not sure if the default telnet client can listen as a server and having the rM be the server poses the challenge of getting the IP from a potential custom ssh host name (this is why I use the PC as a server, since $SSH_CLIENT contrains the IP I need).

For more security one could probably also use a random port to connect to. I didn't use any secret exchange to have the protocol stay as basic as it is over ssh and not require advanced logic on the client side. When adding xor, having a binary for receiving the stream could probably be used anyway and create new possibilities.

[lluchs]

having the rM be the server poses the challenge of getting the IP from a potential custom ssh host name (this is why I use the PC as a server, since $SSH_CLIENT contrains the IP I need).

Couldn't you read the output from ip addr via SSH to figure out the IP to connect to? Having the server on the host is problematic as there's a high likelihood that a firewall is blocking connections there.

[LinusCDE]

having the rM be the server poses the challenge of getting the IP from a potential custom ssh host name (this is why I use the PC as a server, since $SSH_CLIENT contrains the IP I need).

Couldn't you read the output from ip addr via SSH to figure out the IP to connect to? Having the server on the host is problematic as there's a high likelihood that a firewall is blocking connections there.

That would also be a nice way. Not sure how to do this cleanly though. The firewall is defined a concern, but for example my ssh connection is simply called rm when over usb and rm1w when over wifi. Those are not hostnames but rather configs in ~/.ssh/config which then contain the actual IP. Not sure how to detect things like this and maybe other existing surprises properly.

[rien]

@LinusCDE is there a reason you are listening for a TCP connection on the host instead of the client?

[rien]

I've switched the connection around and let restream.rs listen for a connection because of multiple reasons:

• As @lluchs mentions, there could be a firewall running on the host.
• Figuring out the address to phone home to is tricky.
• It seems more intuïtive to let both connections (ssh, tcp) go in the same direction.

Thanks for your contribution! The command line parsing is a nice extra which paves the way for future improvements.

[LinusCDE]

No problem. I personally found it easier finding the requesting ip which is why i used it. But I also didn't factor in the firewall windows has by default.