UltraVNC Version 2 developper recruitment

[Rudi De Vos]

As we continue to bug fix version 1, it is time to move on with version 2.

The first tought was to use RealVNC4 as code base.
But looking at the forum, you see that making connections become more
and more trouble. Nat Firewals etc....
RealVNC4 still use TCP, what is not Nat friendly. We actual need to use UDP. As this would break all compatibility we better move to something else.

UDP require encoder changes. Each packet need to be independed of the previous.

The idea is to use free existing and tested library's for network and graphic stuff. Coss platform (unix/win)

The library's i want to use, are actual made for building Games ????
The graphic game part are always build for speed, yep, that's what we need on the viewer site.
The network lib, is build for using multi player games. As most games are no network specialist, connection is easy.
Making an ULtraVNC connecting need to be as easy as playing a multi-user game.

For thoose who are interested, please take a look at the following

http://www.rakkarsoft.com/
http://irrlicht.sourceforge.net/
http://www.daveandrews.org/articles/irrlicht_raknet/

The project would exist out several parts.
Encoders: We need some encoders that generate independed packets(UDP)
network: Using raknet to build some client/server/master_server
server: data capture/processing etc...
viewer: graphic representation on the screen (via irrlicht it is a 100 line of code)
viewer layer: Buttons menu's , something like the current test V1/2 viewer
Design: If we want to add buttons/icons/logo etc, this time we want somebody responsible for that part. So we don't endup with 18 different styles of graphics.

This need to be discussed !!!
Perhaps the reasons for using RealVNC4 or better then the reasons for not using it.....

[Guest]

I don't understand why you would encourage moving to UDP. You want a protocol that has sequencing and error retries, I'm sure, so then you have to build that on top of UDP, reinventing the TCP wheel.

If you can't get through a firewall with TCP, is it really true that you can easily get through it with UDP???

And what will you do about backward compatibility? Keep it, maintenance headache. Don't keep it, you're effectively a fork, and users who have no control over the server end are stuck with legacy version of UltraVNC. It would be such a shame to see a great product like UltraVNC decay this way.

[rmoller]

Backward compatibilty is necessary, but UDP has great merits as an alternative transport medium. I have tried GPRS, and I could easily stream at full 43 Kbit/s, but any TCP connection would linger around 5-10 Kbit/s. Even if services are improving throughput, there will still be high latency services, where UDP will make a big difference.

BTW. where is the current UltraVnc protocol described?

[uryan]

...You want a protocol that has sequencing and error retries, I'm sure...

Do you? Although you need a reliability layer, TCP was created with different needs and priorities to that which UVNC requires. For example, instead of blindly resending a lost packet, UVNC may be smart enough to recognise that some information is now out of date and send an updated version, reducing redundancy. And UVNC could be designed to process out of order packets, so that it always draws the screen using as much information as it has received, and then fills in the gaps when they arrive. This would be much harder to implement in TCP which assumes that you want to process the information in the order it was sent.

In my mind the great benefit of moving to UDP is not increased NAT friendliness, since I don't really see how it will help with that, but rather the increase in performance and flexibility gained by customising the reliability layer to UVNCs needs

Another area which I thing should change is that updates should be server driven rather than client driven. On a high latency connection this could dramatically drop update times by a second or more.

[zubair_ahmed1]

I am an experienced network programmer in c/c++ and win32 platform.
and i would like to participate in developement of winvnc ver 2. please tell me how could i participate.

[sbostedor]

Are there any security concerns with eliminating the TCP connection and going to a connectionless protocol like UDP? What's to stop things like packet injection attacks?

How would the VNC server and the VNC client handle session encryption?

[cynagen]

You'd need somebody to come up with a reliable protocol standard, and I can help you out with that. Verification and reverification are key to intiating connections and verifying the client is the client we want, and that we're not getting weird packet injections. Also automatic packet drop on injection detection would be a good thing to start thinking about. I'll get to work on drawing up a protocol and standards we can use in UDP. No SYN/ACK on UDP, so let's invent one.

[Rudi De Vos]

The bigest problem from going from tcp to udp is going from
reliable to unreliable connection.

Using udp, you need to implement an extra layer (simular to tcp) that
take care of packet lost, packet order etc...

Most "reliable udp" implementation i tested are slow and generate a big cpu overhead. (http://udt.sourceforge.net/)

[snk12]

Hi,Rudi De Vos

I know a library that can pass the packets through NAT by tcp(GPL & LGPL), Requiring a center server on internet. The library is depend on WinPcap, You can modify the source code for the UltraVNC new version.

http://nutss.gforge.cis.cornell.edu/stunt.php

I have tested before

[cynagen]

The bigest problem from going from tcp to udp is going from
reliable to unreliable connection.

Using udp, you need to implement an extra layer (simular to tcp) that
take care of packet lost, packet order etc...

Most "reliable udp" implementation i tested are slow and generate a big cpu overhead. (http://udt.sourceforge.net/)

The only extra information we'll need to add is a sequence number. We'll do just like what another guy in this thread suggested, go with what we get, and if it doesn't get there in time, oh freakin well. Set a buffer in the application of say 32kb so the buffer will have to be filled, sorted according to packet sequence number, and then displayed. This will add a layer of buffering to catch packet 854 which ends up arriving after 862 due to slow network transmission, so that it can be sorted forward to it's place and then displayed. It's not that hard, and we can certainly go with an adaptive buffering system as well as "go with what you got" type of rendering. It'll make for some shitty images from shitty computers or shitty connections, but either way, we'll get the picture. If we're going to do this lossy shit, I have a few suggestions on how to do it, that is, if anyone is going to listen.

[Rudi De Vos]

Solution is more complex then just dropping updates.
Vnc does not have independed packets, content of a packet depend on previous packet.
12356789
Because you don't have 4, the content of 56789 is not longer valid.

**Resync need to be added.
**Packets need to become independed, a single packet need to contain
all needed info to perform an update and best fit in a single mtu
(Performance drop, compression of small packets is bad compared to bigger) Encoders need to be rewritten
**File transfer, clipboard copy can be corrupted
Vnc does not only distribute video, but also keyboard/clipboard,files....

You proposal is more suitable for 1 server to many viewers using broadcast (LAN), classroom model.
Teacher send his display to students.

Yes, udp works, if you write your application from start to be a udp
aware. Trying to port a tcp written app to support udp is a hell of a job.

[roytam1]

Solution is more complex then just dropping updates.
Vnc does not have independed packets, content of a packet depend on previous packet.
12356789
Because you don't have 4, the content of 56789 is not longer valid.

**Resync need to be added.
**Packets need to become independed, a single packet need to contain
all needed info to perform an update and best fit in a single mtu
(Performance drop, compression of small packets is bad compared to bigger) Encoders need to be rewritten
**File transfer, clipboard copy can be corrupted
Vnc does not only distribute video, but also keyboard/clipboard,files....

You proposal is more suitable for 1 server to many viewers using broadcast (LAN), classroom model.
Teacher send his display to students.

Yes, udp works, if you write your application from start to be a udp
aware. Trying to port a tcp written app to support udp is a hell of a job.

Wrapping to UDP using enet ( http://enet.cubik.org/ / http://enet.bespin.org/ ) can reduce lots of work.

Once UDP protocol is done, we should implement STUN ( http://en.wikipedia.org/wiki/STUN ) for the NAT environment.

Edit: Info. added.
Edit #2: enet URL fixed.

[Rowland]

I'm willing to do some work, because there is some functionality I want and I'm not willing to wait for someone else to get around to it.

What I want:

1. Interoperability with Linux in some fashion
2. Able to get at targets that are behind NAT, without a lot of hassle for the customer.

Now maybe this going to UDP will help with #2 but it doesn't address #1. And it seems to me something like Single Click would solve my needs re #2 if only I were willing to forego #1.

Also I have a pet peeve about this sort of move. Backward compatibility gets broken. UltraVNC already has interoperability problems. It can't talk to Linux. Changing to UDP will break interoperability with ALL previous versions of the software. Is that worth it?

I don't want to get involved in this UDP stuff. It's a distraction. Just reverse the client and server roles and be multi platform at the same time, then I'm happy.

Maybe I'll be so happy I'd be willing to help out with the UDP. But I'd insist on keeping the TCP support in there. The software would be able to do either TCP or UDP. That way everybody wins.

If I can't come to terms with the maintainers of an official version of VNC I'll do a fork. I'd rather not because that just complicates everything. But I'll do it if I have no choice. Maybe I'd fork UltraVNC, maybe I'd fork tightVNC. I'd probably take bits and pieces from each and try to interoperate as much as possible with all the others. It's all GPL, right?

[ACN]

Hi,

Just adding my two cents here:

- I think the idea with using game-related libraries (graphics as well as communication) is GREAT. Games have EXACTLY the same requirements in these departments as VNC, which is to say: Low latency, high bandwidth communication + fast graphics (perhaps this would even help making VNC more "3D aware/capable/efficient", at least down the road...)

- I'm not quite sure why TCP is seen to be "problematic" in relation to NAT/firewalls (in fact, I thought it was the other way around, UDP being "stateless" and thus, I assumed, difficult to handle for NAT), but then again, I'm no network expert. I'm guessing, however, that there could be other significant advantages to using a (more or less) custom protocol on top of UDP. As such, UDP has very low latency and overhead (ie. small headers + no forced/built-in handshaking/retransmission), allowing the "VNC protocol layer" (or whatever existing protocol might be chosen, such as some game-proto) to be very specific to the needs of VNC, without adding all the "generic" stuff present in TCP.

- Since I get the impression that current VNC communication is "sequence dependant" (ie. packet 1 need to arrive before packet two makes sense), it might perhaps be prudent to rethink this - If at all possible without completely breaking VNC compatability? Perhaps something similar to the Ultra-mode could be introduced for communication, allowing UltraVNC servers and clients to negotiate the use of a non-compatible communication method. This way a method allowing lost packets could be considered, which might provide faster updates in some circumstances, such as allowing the client to display (partial) screen-updates, even if some packets are delayed or lost during transmission (since it is often preferable to have the screen updated, even if only partly or somewhat garbled, as opposed to a completely "frozen" screen-image!)

- As others mention, it should be quite possible to implement a protocol (layer) on top of UDP, making it just as reliable as TCP, in case this is necessary. I know this have been done in a number of cases. In fact I must assume this is what MMOG (Massively Multiuser Online Game) developers do on a rutine basis, TCP being FAR to slow and high-latency for most realtime games, which however still require some of their transmissions to be "reliable". I know that such games often use a "mix", allowing certain packets to be unreliable (ie. relative position-changes sent from client to server), while others are sent reliably (ie. absolute positions sent from server to client). If possible, this might also be useful for VNC, since it would remove a lot of overhead, while still allowing certain (ie. important) packets to arrive reliably. For one, I assume that user-input on the client side might well be sent unreliably (users already being used to missed keystrokes/mouse-movements for a number of reasons), while screen-updates from the server might be sent reliably. Even better would be to implement a scheme where only some of the screen-update packets are sent reliably (ie. key-frames / screen-refreshes), while others (ie. "delta-packets" or whatever) could be sent unreliably (this might well cause the abovementioned VNC-compatability issues however?)

- I would like to take this oppertunity to encourage developers to consider audio-transmission when/if a new protocol is considered for VNC. While I've previously suggested that audio-support for UltraVNC be implemented by using existing external applications (ie. Skype or similar), more or less integrated with / controlled by VNC, the ideal would of course be to have audio support integrated directly in VNC. In case of the latter, it would likely be a good idea to take this into consideration when developing the communication protocol. A good audio implementation might even allow for (perhaps partly) unreliable communication, but will require low latencies, possibly even redundancy (to compensate for lost packets).

Anyway, just my inexpert opinions here. Keep up the good work developers, I'm looking forward to the next iteration of UVNC with great anticipation...


Regards,

Adam.

[Rowland]

Hi,


- I'm not quite sure why TCP is seen to be "problematic" in relation to NAT/firewalls (in fact, I thought it was the other way around, UDP being "stateless" and thus, I assumed, difficult to handle for NAT), but then again, I'm no network expert. I'm guessing, however, that there could be other significant advantages to using a (more or less) custom protocol on top of UDP. As such, UDP has very low latency and overhead (ie. small headers + no forced/built-in handshaking/retransmission), allowing the "VNC protocol layer" (or whatever existing protocol might be chosen, such as some game-proto) to be very specific to the needs of VNC, without adding all the "generic" stuff present in TCP.

TCP does have latency problems and that's annoying. But it's not a show stopper.

The chief problem with TCP and NAT is VNC by default listens on the target host. If the target host is behind NAT there's no easy way for the operator host to connect to it. There are things the client user can do to his NAT router to get around this but that's not good enough.

There's a way to make the operator host (vncviewer) listen and the target host call out. That gets around the NAT problem so long as vncviewer isn't behind NAT. But here's the same problem. It's complicated for the client user to set up. That's why I'm interested in Single Click. But Single Click isn't compatible enough for me.

I don't know how or why UlraVNC and tightVNC got forked off so far from each other. I wish I knew. All I know is it's gumming up the works with interoperability problems.

[X3]

I could help with the Graphics bit if you already dont have anyone working on it.

However while I would love to help I should also let you guys know I work full time and also am doing a course so some things could take a bit longer but they would happen.

I need to know all the relevant details. pm me and I will give my live messenger ID or IRC (freenode) or both...

Laters.

[remotepc]

Any updates on this ?
I know Rudi has used GNAT wrapper based on libjingle which basically deploye and use google talk network services infrastructure for the same , But is it possible to have an independent sort of uvnc version ?

Regards
Manu

[gjpc]

I would think about helping out some, but the developers all ignore my requests for help on this forum.

www.circlesoft.com

[faali]

Any one is working on forcing VNC to use udp instead of tcp?
I need help regarding this..

[redge]

Any one is working on forcing VNC to use udp instead of tcp?

maybe yes, but most of majority developers know or/and found how to do, do it for his own business .... not for open source community.

if over UDP, is it backward compatible VNC TCP ?

[faali]

Any one is working on forcing VNC to use udp instead of tcp?

maybe yes, but most of majority developers know or/and found how to do, do it for his own business .... not for open source community.

if over UDP, is it backward compatible VNC TCP ?

yes possible, depends upon port(TCP/Udp) on which you are sending/receiving data...

[Rudi De Vos]

The biggest problem is that udp is unreliable.
Packets arrive in different order or just get lost...

This mean you need a reliable upd implementation. But most libs
that does it have a big cpu overhead and are slower.

To stay compatible you best create a tcp<->udp and udp<->tcp converter. Then you can use the current vnc version and let it connect in loopback that the converter.
Then you need to add some nat punching for nat2nat connections.
A lot easyer for testing when convertor/connector is a seperate exe.

If this works reliable... later, you could import the udp code in vnc as an option switch.

[shenglu]

If the target host behind NAT there is no simple way for operators to connect to host it. A client user can do his NAT router to solve this problem of things, SPAM SPAM SPAM but not good enough.

[B]

This is so sad -- shenglu is a spammer, but for a vendor I had up until this moment respected - Meritline. How sad! MERITLINE IS A SPAMMER (if only by proxy) NOW FOLKS. You may choose to stay away from MERITLINE SPAM.

[edens]

There are support punycode?
(For non-English-speaking countries)
ex.
VNC Server:你好.dyndns.xx
This type of.