https://github.com/fiddyschmitt/SimpleKVM

https://github.com/fiddyschmitt/SimpleKVM

https://github.com/fiddyschmitt/SimpleKVM

If you only have two computers, you just need one instance of SimpleKVM to switch between the computers.

As others have mentioned, you can use a cheap USB switch if you don't have an in-built KVM.

DDC/CI is quite interesting. Most OEMs seem to implement it just fine. But some (like LG) need special handling.

The most popular feature request was to tunnel over S3 buckets. I was surprised it worked. The latency is high (3 seconds) but the bandwidth is high enough to stream a 1080p video from YouTube. Overall, it has similar performance to internet through geosynchronous satellites.

The upgrade took the better part of a year and the trickiest part was catering for the various ways the file systems synchronise. Some are fast, some are picky about open file handles, some require IO operations to be retried.

My favourite aspect of File Tunnel is people using it in ways I never anticipated, such as:

    * Allowing two VMs to communicate without networking enabled (via VirtualBox Shared Folder)

    * Providing internet to a remote RDP session by creating a reverse tunnel to a local SOCKS proxy.

    * Controlling a vending machine through an FTP server meant for beverage logos.

Comments URL: https://news.ycombinator.com/item?id=45894748

Points: 2

# Comments: 0

https://rdp2tcp.sourceforge.net/

In the future I will implement a single file to handle both directions.

Arbitration was indeed one of the trickiest bits. Originally I pre-reallocated the full file size (10 MB). Then used an integer at the beginning of the file to signal to the other side that a block was ready. The other side repeatedly read that int, and read the corresponding part of the file. But writing twice (once for the data, once for the int) had a significant performance impact.

In the end, what worked best was not pre-allocating the file. Rather letting the file grow whenever the writer writes to it. The reader knows when data is available by doing a PeekChar() in a tight loop. It's surprisingly fast, and accurately reflects the state of the file.

1. It gracefully supports each side of the tunnel turning on and off.

2. It accepts any number of clients, and forwards them through the tunnel.

3. It recycles the shared file.

The key to high performance as you rightly pointed out was preventing flushing. In the end, what worked best was reducing the number of writes to disk (which is the bottleneck). I did that by buffering 10-50 ms worth of TCP data, coupled with only flushing explicitly (using a large buffer so that neither BinaryWriter or FileStream flush automatically).

A file tunnel can be used to enable a client to reach a server.

Comments URL: https://news.ycombinator.com/item?id=40561527

Points: 3

# Comments: 1

People have used it for interesting things:

- Bridging connections which would otherwise be blocked by a firewall

- Tunneling through RDP (similar to an SSH tunnel)

- Exposing a localhost web server to others

Key features I put effort into:

1. The shared file is restarted every 10 MB, so it doesn't grow indefinitely.

2. Optimisations for latency & bandwidth. (800 Mbps on a Gigabit LAN. 108 Mbps if file tunneling through RDP)

3. Synchronisation between two sides (each side can be started and restarted in any order)

I'd love to hear about any weird and wonderful uses you might have for it.

Thanks, Fidel

Comments URL: https://news.ycombinator.com/item?id=40553267

Points: 180

# Comments: 37