Ann: Appendix 2A, page-31

>I would really appreciate any technical reasons the technology is problematic or irrelevant.

I have tried to dumb it down before, but no one was interested. You will find it in my posting history if you go looking.

The fundamental reason is that the VIN product tunnels a TCP stream by breaking it into discrete chunks and sending those chunks via UDP datagrams. TCP is a reliable protocol, and UDP is not, so VIN is sending reliably protocolled data over an unreliable transport method. That works in a lab because on closely controlled networks even unreliable protocols like UDP tend to work perfectly well. The datagrams arrive at their destination reliably and in the correct order. On the open internet, where UDP datagrams will be dropped at the first sign of congestion, or where data can take different routes and arrive in a sequence other than the one they were sent in, the idea falls apart.The problem is described here:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

which, as per the document title, covers "Why TCP Over TCP Is A Bad Idea". TCP over UDP, which is what VIN does, is an even worse idea.

Source: the above is from my direct and personal experience from several years ago. The current VIN client (from 2019) appears to work in exactly the same way as it did back then.

The other issue is that the data is transmitted across UDP ports which almost all firewalls do not recognise, and hence block. When the iWebGate guys (who are no longer working for Netlinkz as far as I know) tried to get VIN working on my client's network they had to get me to open various network ports in order to let the data through. That approach does not scale. If they sell VIN to millions of Chinese users, those users will all have to fiddle with their firewall settings. That is not going to happen.