| Blog |
|
| Releases |
| UDP and Ubuntu 14/Windows incompatibility | |
|---|---|
|
Date: 14/9/2017 Tags: linux ubuntu networking | For the last few weeks I've been mucking around in the background with an application I've called "ClipShare" that basically sits on the network and allows you to copy and paste between different machines. It supports text, images and files at the moment. I'm sure such a thing already exists but I like how it auto-detects all the machines running it on the network via UDP broadcast and supports Windows, Mac and Linux. It's far from production ready, it still crashes a bit and hangs up during file transfers sometimes. But over time I'm sure I'll iron that out. Things like Samba, VNC and VM's (Vmware/Virtualbox) tend to have support for things like clipboard and file sharing. But in my experience they break very easily and it's 50/50 if they'll work or not. Hence having an alternative for getting the data across. In testing I had a Ubuntu 14 VM running on a Windows host and for the life of me couldn't get the UDP packets to go from Ubuntu to Windows. I could see the packets arriving in Windows land via Wireshark but the recvfrom wouldn't get the packet. The packet wasn't large, just 40 bytes or so. In researching the issue I found that IP packets have a checksum, so I figured out how to get Wireshark to test the checksum. It confirmed the checksum was good. I could see using 'netstat -s' that there was an increasing count of 'Received Packets Discarded'. So Windows for reasons unknown was discarding the UDP traffic from Ubuntu. I tried turning off the Windows Firewall. No difference. So then I decided to spin up my Ubuntu 16 VM and test the exact same code there. And sure enough it's working fine. So in conclusion I believe that at the OS level, Ubuntu 14 has some busted networking code. I can't tell what's wrong. Maybe it's a Windows thing. But it's basically meant I'm moving to Ubuntu 16 for all my Linux dev stuff. The main reason I had a Ubuntu 14 environment was that I had a working Raspberry Pi cross compiler install and I hate messing with a working env just for the sake of upgrading. However that broke recently anyway so it seems that the last reason for keeping 14 just disappeared. Fun times. |
| (1) Comment | Add Comment | |
| Apple and the curse of VNC | |
|---|---|
|
Date: 8/9/2017 Tags: mac vnc | For many years now it's annoyed me greatly that trying to connect a Windows VNC client to a MacOSX VNC server has resulted in terrible horrible slow and glitchy performance. Mac to Mac is fine, Windows to Windows is fine, but cross platform? Nope. In fact the Mac to Mac performance is better than any of the Windows or Linux implementations. The reason being that Apple has added a range of proprietary extensions to make that use case better than normal VNC. This is also why the Windows -> Mac case is sub-optimal. It seems that the fast VNC modes that everyone else talks aren't spoken by the Apple VNC server implementation. So what to do? Well the solution that I'm employing at the moment is to... not use the Apple VNC server implementation! Turn off screen sharing in the options and install
VNC connect. The cross platform performance is quite decent, running the server and client from the same vendor. Maybe 90% as fast as the all Apple case? Embrace, extend, extinguish am I right? You either die a hero or you live long enough to see yourself become the villain. (I will try and find a free solution in the medium term, and will update this post if/when I do) |
| (0) Comments | Add Comment | |