Re: Disconnect when switching users XP
Den 2011-03-15 17:48 skrev Long, Phillip GOSS: Dale: We use UltraVNC on our Windows machines, and it's free as far as I know (I'm not involved in licensing and that kind of noise). I have had better luck with the UVNC server than with the Real one, but the vncviewer works about the same. RealVNC maintains the protocol, and when UVNC, TightVNC, etc., want to create some new kind of packet, they apply to RealVNC for a number, and AFAIK, RealVNC gladly hands it out. I'm guessing that UVNC was written by guys more familiar with MSWindows (only because it's not on other platforms, not because of code quality; I haven't really compared the codebases). I think the protocol is designed so that unknown packet types are ignore/dropped, so that a viewer and a server can always talk to one another, provided that they're both using the same *version* of the protocol. That's the beauty of RealVNC maintaining the protocol for everybody; all the various flavors can all talk with one another (again, if they use the same version). If U're having trouble with a viewer and a server from different packages not communicating, it could be because they're not both using the same version of the protocol. But UltraVNC is not conforming to the protocol. The UltraVNC client has a chance to work with all other *current* RFB conforming servers, but a client that is strictly conforming to the RFB protocol cannot communicate with the UltraVNC server. UltraVNC extended the protocol without coordinating with the RealVNC protocol maintainers, and as a result everybody else must select if they should have warts in the code that is outside the specs (and a possible broken implementation should RealVNC decide to use the mechanism used by UltraVNC for something of their liking) or drop support for communicating with the UltraVNC server outright. UltraVNC is in the embrace-and-extend camp and is a nasty piece of work if you ask me. Sure, other implementations also extend the RFB protocol, but most do it without sacrificing interoperability. Or, at least they try to. Caveat emptor: This was the situation last time I had a look, but I doubt it has changed since. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: 3.8 Specification Palette color ambiguity
Den 2009-09-24 18:29 skrev Jon Watte: Peter Rosin wrote: Den 2009-09-24 01:41 skrev Jon Watte: In SetColourMapEntries, are the color values high-justified (most significant bits) or left-justified (least significant bits -- if so, how many?) Huh? All 16 bits are significant. Which means high-justified. And low-justified. And centered. *All* bits are significant. You should think about why you are not arguing for similar language for e.g. red-max in PIXEL_FORMAT? Thanks for the answer! You're welcome! Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: 3.8 Specification Palette color ambiguity
Den 2009-09-24 01:41 skrev Jon Watte: In SetColourMapEntries, are the color values high-justified (most significant bits) or left-justified (least significant bits -- if so, how many?) My guess is high-justified, but the spec leaves this up to the imagination, so I thought I'd check to make sure. Sincerely, Huh? All 16 bits are significant. If you want to insert something with fewer bits (as a server), I suggest you duplicate your bits until all the bits are filled. E.g. if you have a 5-bit intensity 01001b, I suggest that you send 01001 01001 01001 0b, or 0x4a52. If you only need less (as a client), I suggest you grab the most significant bits. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Negotiating server screen size
Den 2009-09-14 21:37 skrev Christophe Lohr: So, I wonder if a protocol extension could be interesting. Isn't it? Look here: http://www.tigervnc.org/cgi-bin/rfbproto And search for ExtendedDesktopSize. I don't know what implementations support that extension though... Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: VNC multihead and size change extension
Den 2009-03-13 13:01 skrev Pierre Ossman: Hi, We've been working on client initiated screen size changes and need to extend the protocol to do that. In order to minimise the number of extensions, we'd also like to accommodate multi-head configurations with this new protocol. So we'd like your feedback on the protocol, and allocation of one new client to server message and one pseudo encoding. Hi Pierre! There is also the WMVi pseudo-encoding (0x574d5669, or WMVi in FourCC) to consider. A problem with this new proposal is that *both* WMVi and this multihead scheme are better than the DesktopSize pseudo-encoding. But the multihead scheme doesn't do the stuff that WMVi does (i.e. handle server side pixel format changes). I fear that appempts to implement support for both WMVi and this proposal will lead to undesired complexity. So, I'm asking for a way to incorporate server side pixel format changes in this proposal so that it can superseed both WMVi and DesktopSize. That said, there is one thing that I don't like about WMVi, and that is the fact that the server changes the wire pixel format without a chance for the client to say no. I would not mind at all if that was revised, should a pixel format changes be added to this proposal, so that the server instead simply informed that its preferred pixel format has changed. The client would then be in full control of what pixel formats it needs to support, and my feeling is that this is more in line with the spirit of the RFB protocol. Even if it wouldn't add needless complexity if the server were to send a WMVi rect for some changes and a ExDesktopSize rect for some other changes and perhaps two rects for some classes of changes, I still think there is value in an advisory notification that the server has changed its preferred pixel format, and this seems like a good opportunity to sneak that into the RFB protocol ;-) Here's a description of WMVi: http://wiki.multimedia.cx/index.php?title=VMware_Video And lastly, some comments on details in the proposal: There is no way for the server to tell a client how it can change its SetDesktopSize message so that it gets something that is ok for the server. If e.g. the server has some resource limit that prevents it from making framebuffers wider than 2048 pixels (just an example, the example has no bearing on any particular HW), then the server has no way to indicate to the client that it must keep below that limit. One way to solve that would be for the server to fill in the ExtendedDesktopSize rect with values that may work better when y-position is non-zero, instead of simply echoing the current state (which the client should already know). But perhaps that would be too complex. My main point is that it's very limitied to only have 16 bits (the y-position) to describe a problem. Perhaps an error string? The x position of the pseudo-rect indicates the reason for the change, and an ExtendedDesktopSize pseudo-rect should also be sent in response to non-incremental FrameBufferUpdateRequests. I'm missing non-i FBUR as a reason in the enumeration (even if that isn't a /change/ as such). Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: VNC multihead and size change extension
Den 2009-03-16 11:45 skrev Pierre Ossman: On Mon, 16 Mar 2009 10:44:07 +0100 Peter Rosin wrote: Hi Pierre! There is also the WMVi pseudo-encoding (0x574d5669, or WMVi in FourCC) to consider. A problem with this new proposal is that *both* WMVi and this multihead scheme are better than the DesktopSize pseudo-encoding. But the multihead scheme doesn't do the stuff that WMVi does (i.e. handle server side pixel format changes). I fear that appempts to implement support for both WMVi and this proposal will lead to undesired complexity. So, I'm asking for a way to incorporate server side pixel format changes in this proposal so that it can superseed both WMVi and DesktopSize. I don't see a huge gain from including it into these message. We could just as well implement the server pixel format hint as another pseudoencoding. Since it is a strict server-to-client communication, we don't need to think about allocations in the more limited command space. That said, there is one thing that I don't like about WMVi, and that is the fact that the server changes the wire pixel format without a chance for the client to say no. I would not mind at all if that was revised, should a pixel format changes be added to this proposal, so that the server instead simply informed that its preferred pixel format has changed. The client would then be in full control of what pixel formats it needs to support, and my feeling is that this is more in line with the spirit of the RFB protocol. That would be very against the RFB mentality, yes. But the wiki entry you pointed to suggests that these encodings are just used for offline rendering. At that point there is no possibility for the server to adjust to the client's need, so you have to mandate that the client will use the server's native format. WMVi is implemented by QEMU, gtk-vnc, ggivnc and more, so it's certainly not just offline rendering. I don't know why QEMU selected WMVi for adding pixfmt notifications, but they did. If you want to get full use out of QEMU you need to implement WMVi. Even if it wouldn't add needless complexity if the server were to send a WMVi rect for some changes and a ExDesktopSize rect for some other changes and perhaps two rects for some classes of changes, I still think there is value in an advisory notification that the server has changed its preferred pixel format, and this seems like a good opportunity to sneak that into the RFB protocol ;-) I agree that such a hint could be useful. I'm not convinced it needs to be included in these messages. Besides, a server and client should implement support for all variants anyway to give good backwards compatibility. I only suggested it since WMVi is in-use already, and having one superior way to handle desktop changes is always going to be easiest, then the other methods become legacy. You can also focus on implementing each of them separately, and not on how they interact with each other. Sure, for ultimate support, a client *should* handle a server switching between DesktopSize and ExtendedDesktopSize, but both you and I know that a server which has a client supporting both is very unlikely to switch between them. It will go with ExtendedDesktopSize and be done with it. But if the server also sees WMVi support there are more than one way to send changes (WMVi first or WMVi last), and it then becomes harder to verify that a client behaves correctly in all cases, since the server you have available might not behave similar to the one next door and which you have not tested against. Adding pixel format change support in the ExtendedDesktopSize will end all that - there will be a simple path and all sane servers will follow it. Less headaches for everybody. And lastly, some comments on details in the proposal: There is no way for the server to tell a client how it can change its SetDesktopSize message so that it gets something that is ok for the server. If e.g. the server has some resource limit that prevents it from making framebuffers wider than 2048 pixels (just an example, the example has no bearing on any particular HW), then the server has no way to indicate to the client that it must keep below that limit. One way to solve that would be for the server to fill in the ExtendedDesktopSize rect with values that may work better when y-position is non-zero, instead of simply echoing the current state (which the client should already know). But perhaps that would be too complex. My main point is that it's very limitied to only have 16 bits (the y-position) to describe a problem. Perhaps an error string? Strings are not machine parsable, nor translatable (unless you mandate exactly what they should say, at which point you might as well use a code for them). And yet the protocol is already full of strings, so you have to deal with that already. But if you dislike strings so much, what was wrong with the machine readable proposal? Just because the server has a way to report back something
Re: VNC multihead and size change extension
Den 2009-03-16 15:00 skrev Pierre Ossman: On Mon, 16 Mar 2009 13:29:38 +0100 Peter Rosin wrote: Den 2009-03-16 11:45 skrev Pierre Ossman: That would be very against the RFB mentality, yes. But the wiki entry you pointed to suggests that these encodings are just used for offline rendering. At that point there is no possibility for the server to adjust to the client's need, so you have to mandate that the client will use the server's native format. WMVi is implemented by QEMU, gtk-vnc, ggivnc and more, so it's certainly not just offline rendering. I don't know why QEMU selected WMVi for adding pixfmt notifications, but they did. If you want to get full use out of QEMU you need to implement WMVi. Annoying. Do they also rely on putting the conversion requirements on the client? Yes. If a client claims support for WMVi, it has to support all pixfmts (or disconnect on reception of something unlikeable). I agree that such a hint could be useful. I'm not convinced it needs to be included in these messages. Besides, a server and client should implement support for all variants anyway to give good backwards compatibility. I only suggested it since WMVi is in-use already, and having one superior way to handle desktop changes is always going to be easiest, then the other methods become legacy. You can also focus on implementing each of them separately, and not on how they interact with each other. Sure, for ultimate support, a client *should* handle a server switching between DesktopSize and ExtendedDesktopSize, but both you and I know that a server which has a client supporting both is very unlikely to switch between them. It will go with ExtendedDesktopSize and be done with it. But if the server also sees WMVi support there are more than one way to send changes (WMVi first or WMVi last), and it then becomes harder to verify that a client behaves correctly in all cases, since the server you have available might not behave similar to the one next door and which you have not tested against. Adding pixel format change support in the ExtendedDesktopSize will end all that - there will be a simple path and all sane servers will follow it. Less headaches for everybody. I'm not sure I see the complexity. If a server wants to support all three methods, it can send all three rects. The only requirement that must hold is that the information in the different versions do not conflict. Admitted, having WMVi for just sending hints about the server's native pixel format can be a bit heavy. But I think it would be better replaced by a pseudoencoding that does only just that. Including that information here just makes the screen geometry handling seem more complex. (In a perfect world I'd have framebuffer size and virtual screen setup be completely separate as well, but that would mean that we would need two client-to-server commands and that would be wasteful given the limited space of command codes.) Ok, you clearly don't want pixfmt mixed into this, so I'm dropping that ball on the floor. Strings are not machine parsable, nor translatable (unless you mandate exactly what they should say, at which point you might as well use a code for them). And yet the protocol is already full of strings, so you have to deal with that already. It's just the authentication as far as I can see. And that something in the existing protocol is bad is hardly an argument for making additions equally bad. Ok. But if you dislike strings so much, what was wrong with the machine readable proposal? Just because the server has a way to report back something that should work doesn't mean it has to do much work to do so, a lazy server-side implementation can send back the currently active config and be done with it. The idea isn't fundamentally bad, it's just that describing restrictions is a can of worms and I don't think its a good idea to add features that you don't have a plan as to how they should be used. When it comes to this specific problem, the current protocol suggestion should already handle it: The x-min, y-min, x-max, and y-max indicates server imposed limits of the framebuffer. The client can use this information to indicate to the user when resizing (using SetDesktopSize) is possible. Ah, right. Bad example... So, take some other example: there is some limit (for whatever stupid reason) on the server so that it supports maximum 17 screens. Or it might not support overlapping screens. Or all screens have to be the same size. Use your imagination... Indeed, but describing such limitations can be very difficult. How do you describe the non-overlapping requirement for example? I don't see the method of requesting one thing and potentially getting something completely different back as a decent solution. In most cases it will just be plain confusing. Could you describe how the client could suitably react to such a response? I wasn't proposing that the exact restrictions were described. I didn't propose
Re: VNC multihead and size change extension
Den 2009-03-16 18:15 skrev Pierre Ossman: On Mon, 16 Mar 2009 16:54:20 +0100 Peter Rosin wrote: Den 2009-03-16 15:00 skrev Pierre Ossman: Annoying. Do they also rely on putting the conversion requirements on the client? Yes. If a client claims support for WMVi, it has to support all pixfmts (or disconnect on reception of something unlikeable). But what if the client doesn't claim to support it? Seems like they have to implement format conversion in the server anyway. Oh yes, they do it in the server too. One reason to go with WMVi might be that the server doesn't need to do a lot of conversions during a pixfmt change as all clients are forced to follow the server preference. But I also think you could have evaded that with a single rect update that only specifies a new pixfmt preference, instead of an update starting with a WMVi rect and then a full update in the new pixfmt following. The client would then get a chance to change pixfmt without the server doing any conversions. And the clients could be kept simpler. As is, I think QEMU simply disconnects clients that does not support WMVi, should its preferred pixfmt change. But a client can still request whatever pixfmt it wants, it's just when the preferred pixfmt changes that the server disconnects all non-WMVi clients. But that is from memory and it might also have changed since I looked? Indeed, but describing such limitations can be very difficult. How do you describe the non-overlapping requirement for example? I don't see the method of requesting one thing and potentially getting something completely different back as a decent solution. In most cases it will just be plain confusing. Could you describe how the client could suitably react to such a response? I wasn't proposing that the exact restrictions were described. I didn't propose that the server response would actually be used, it would just be a hint so that the client would have at least some request that worked. But the client would probably need to adjust the server reply further. An example (using monospace font): Server has two screens 1024x768, side-by-side, fb-size 2048x768. - | | | | | | | | | - Client the asks for the initial two screens, plus a third screen 800x600 which is halfway overlapping the rightmost screen, fb-size 2448x768. - | | | | | | | | | | | | | - Server says no (since it can't handle overlapping screens) and informs the client that it could change its request to not have any overlaps, i.e. make the third screen only 400x600, fb-size still 2448x768. - | | | | | | | | | | | - The client can then do what it wants with that info. If it takes it, it could render on only half its third screen. Or the server might decide to move the overlapping screen to the right instead. And since it has no idea what the client's restrictions are, the client might need to readjust what the server wants. And then things quickly spiral out of control. :) But if the server suggests that, its suggestion isn't smaller than the client request *in all aspects*. But yes, there could potentially be many roundtrips and still no working end result. But that is equally true if the server is only saying no. A mechanism that allows the client to handle server side limitations would be fantastic. But the only solutions I see either cannot describe all the possible limitations, or start to cross over into the whole implementation defined neck of the woods. And implementation defined is the greater evil IMO, so I've opted for an incomplete, but common set of restrictions. We might want more/other fields than what I've proposed, but the whole throw stuff at the server and see what comes back approach does not give me a good feeling. Ok, you don't like it. I was only a suggestion that popped up in my head. Since it is nearly impossible to envision all possible server side limitations, we shouldn't even try. Instead, let the server come up with one possible workaround for the client, but never force that suggestion on the client. The client can always request something completely different, should it dislike the server suggestion. People tend to follow popular implementations, not the specification. So I don't think we should add anything on the premise might be useful, perhaps, but everyone else can just ignore it as there is a high risk of implementations popping up that rely on this optional behaviour. I believe the only sane way is to have a set of restrictions where the client can compute beforehand if a request will fail, and a failsafe of the server saying no for the restrictions that we were unable to describe. The server might for example be saying no just because it doesn't allow any
Re: Request for allocation of new security type code for SASL auth
Den 2008-12-17 11:53 skrev Daniel P. Berrange: On Wed, Dec 17, 2008 at 08:56:02AM +0100, Peter Rosin wrote: *snip* 1. Is there any compelling reason to *not* sasl_encode/sasl_decode the 6.1.3 SecurityResult message when there is a SSF layer? I think using sasl_encode/sasl_decode on that message as well would simplify implementations, as the need to hook in after the SecurityResult disappears. It would be enough to make the needed stream modification while still running in sasl territory. One of the possible reasons for sending back a 'failed' SecurityResult is if the server determines that the negotiated SASL SSF layer is not suitably strong for its needs, or if the authenticated username was not allowed by the ACL. In such a scenario, the server may not wish to go to the bother of using sasl_encode on the securityresult when it knows it is sending back a reject/failure message dropping the connection. I've got proof of concept implementations of this spec for QEMU and VINO (based of libvncserver) and its not caused any serious complications in the code so far. Ok, cool. Thanks for clarifying! BTW, I didn't expect serious complications either... :-) NB, there are only two common SASL mechanisms which provide SSF layers, GSSAPI (Kerberos) and DIGEST-MD5. DIGEST-MD5 is deprecated as it is considered to be an insufficiently secure negiation. The other SASL mechanisms all rely on the underlying connection to provide encryption. As such, with exception of people using Kerberos, for SASL to be secure you'd want to have the VeNCrypt security type active with one of its x590 based modes, or tunnelling over SSH, or another TLS like protocol extension (VINO has one - Security type 18, TLS - but as currently implemented it is not sufficiently strong because it uses anonymous diffie-hellman credentials instead of x590 certs - this is to be fixed). But can you really use the VeNCrypt security type like that without extending its spec (or using unofficial numbers)? What VeNCrypt subtypes do you plan to use to activate TLS/X509 and at the same time trigger the SASL security type? It seems that there is need for two new VeNCrypt subtypes (TLSSASL and X509SASL or something) for VeNCrypt and SASL to mix nicely. Ah, and also, can you please register the SASL security type with the Tight project (they need a four character vendor representing either a person, an organization or a product and an eight character name, both padded with underscores. I.e. something like product:VINO and name:SASL) so that someone can request the SASL security type after opening the Tight security type. *snip* Thanks for the corrections/typos spotted in the spec My pleasure :-) Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Request for allocation of new security type code for SASL auth
Hi again! Sigh, sorry to reply to self, I guess the best was to find bugs is to make a public statement of some sort... Den 2008-12-17 08:56 skrev Peter Rosin: --- README.sasl.orig2008-12-17 07:19:28.046875000 +0100 +++ README.sasl.new 2008-12-17 07:21:50.43750 +0100 @@ -174,5 +174,5 @@ If the sasl_server_start call is successfull, the returned -serverout data will need to be sent to the server. +serverout data will need to be sent to the client. @@ -201,5 +201,5 @@ clientin, clientinlen, -servertout, +serverout, serveroutlen); clientin and clientinlen don't need the address-of operator () here. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Request for allocation of new security type code for SASL auth
Hi!
Den 2008-12-14 17:53 skrev Daniel P. Berrange:
I have defined a mapping of the SASL authentication scheme into the RFB
authentication protocol. Please could you allocate an official security
type code for use with this auth scheme, under the name SASL.
*snip*
I looked a bit at this and spotted a few typos, see diff in
attachment (I replaced 100 with 20 before making the diff, I figured
those changes were not very interesting).
I also have a couple of questions:
1. Is there any compelling reason to *not* sasl_encode/sasl_decode
the 6.1.3 SecurityResult message when there is a SSF layer? I think
using sasl_encode/sasl_decode on that message as well would simplify
implementations, as the need to hook in after the SecurityResult
disappears. It would be enough to make the needed stream modification
while still running in sasl territory.
2. Not knowing much about SASL, I'm curious to know if this security
type is useful on reversed connections? Are there any implications
to consider?
3. And finally, does this security type spec have a home somewhere on
the Internet?
Cheers,
Peter
--- README.sasl.orig2008-12-17 07:19:28.046875000 +0100
+++ README.sasl.new 2008-12-17 07:21:50.43750 +0100
@@ -174,5 +174,5 @@
If the sasl_server_start call is successfull, the returned
-serverout data will need to be sent to the server.
+serverout data will need to be sent to the client.
@@ -201,5 +201,5 @@
clientin,
clientinlen,
-servertout,
+serverout,
serveroutlen);
@@ -219,5 +219,5 @@
write_u8(1)
} else {
- write_u8(0)
+ write_u32(0)
write_u8(0)
}
@@ -241,5 +241,5 @@
If the sasl_client_step call is successfull, and the previously
-received 6.2.20.3 sever start' or 6.2.20.5 server step
+received 6.2.20.3 server start' or 6.2.20.5 server step
message had the continue value set to 0, the client protocol
continues to 6.2.20.6 client security check. The final call
@@ -267,6 +267,6 @@
sasl_client_step(saslconn,
- serverin,
- serverinlen,
+ serverin,
+ serverinlen,
clientout,
clientoutlen)
@@ -320,6 +320,6 @@
err = sasl_server_step(saslconn,
- clientin,
- clientinlen,
+ clientin,
+ clientinlen,
servertout,
serveroutlen);
@@ -340,5 +340,5 @@
write_u8(1)
} else {
- write_u8(0)
+ write_u32(0)
write_u8(0)
}
@@ -354,5 +354,5 @@
At this point the client and server have completed the SASL negotiation
-process. If the client had requested an SSF layer during its initial
+process. If the client had requested an SSF layer during its initialization
it should now validate that a suitable SSF layer was negotiated with
the server. If the SSF layer is unsuitable it shall drop the connection
@@ -380,5 +380,5 @@
The client and server are now authenticated, but before continuing, if
-the server had requested an SSF layer during its initial it should
+the server had requested an SSF layer during its initialization it should
now validate that a suitable SSF layer was negotiated with the client.
If the SSF layer is unsuitable it shall send a 6.1.3 SecurityResult
@@ -386,5 +386,5 @@
connection to the client.
-If the SSF layer is enabled, and suitable for the client, all messages
+If the SSF layer is enabled, and suitable for the server, all messages
transmitted over the RFB protocol AFTER the 6.1.3 SecurityResult
message shall be passed through the sasl_encode API, and all messages
___
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Protocol extension for changing desktop name on the fly
On Tue, Jan 08, 2008 at 10:20:50AM -, James Weatherall wrote: In practice desktop names are currently ASCII-only, but new standard RFB protocol elements all use UTF-8 for string data. I'd recommend that third-party encodings, etc also use UTF-8 for string data for consistency. So, Peter, did you settle for ASCII-only or did you change to UTF-8? (I need to know so that my implementation is compatible) Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Protocol extension for changing desktop name on the fly
On Mon, Jan 07, 2008 at 05:02:25PM +0100, Peter Estrand wrote: NumberName -306 DesktopName pseudo-encoding Bzzzt -307 :-) Here's the description: A client which requests the DesktopName pseudo-encoding is declaring that it is capable of coping with a change of the desktop name. The server changes the desktop name by sending a pseudo-rectangle with the DesktopName pseudo-encoding in an update. The pseudo-rectangle's x-position, y-position, width, and height must be zero. After the rectangle header, a string with the new name follows. There are more than one popular way to encode strings, which one have you selected? U32 name-length followed by U8-array name-string as in the ServerInitialisation message? Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On Wed, Dec 12, 2007 at 01:50:38PM -, James Weatherall wrote: Hi Anon, This is a know limitation of the Refresh Screen option in VNC Free Edition VNC Free Edition-based software, which isn't safe to use if the VNC Viewer might be changing pixel format at a later point. Nice to see it confirmed, I have been thinking about this for a while but never got around to formulating it in an email. Also, you seem to hint that this isn't a problem in the closed sourced versions, can you enlighten us as to how the problem was resolved, if it has indeed been resolved? You shouldn't need to use Refresh Screen, in general. Well, that puts limitations on the client implementation. Just as an example, imagine a client that draws in a framebuffer and that the user changes screen resolution (or that some other application borrows the framebuffer). The client has only one thing to do when it wants to refill the framebuffer, if it is not allowed to send a full refresh request: keep a private copy. That isn't too nice, given this is a thin client protocol. Oh, right, the client can wait for the next update to be issued as well and then send a full update request, but that can be a lng wait. Not too nice either... When the solution is a simple as introducing a pseudo-encoding that gets sent (if requested of course) as an empty rect before any rect with the new pixfmt is sent, why not introduce that? That would make the protocol more robust, and is easy to implement. The client has to take care not to have two pixfmt changes on the wire simultaneously though, but that's not too much of a limitation. (Other solutions are of course also possible, this is just the first that came to mind) Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On Thu, Dec 13, 2007 at 10:09:07AM -, James Weatherall wrote: Hi Anon Peter, The VNC Personal Enterprise Editions use a new scheme that does not have this limitation. You won't hit problems with the VNC Free Edition system unless you send multiple outstanding update requests (as is the case when using Refresh Screen), *and* you change the on-the-wire pixel format *after* having done that. Hi Wez, I'm not talking about the VNC Free Edition system, I'm talking about the protocol and what clients should do. The problem is that if a client wants to do a pixfmt change it has to wait for an outstanding FramebufferUpdateRequest to be satisfied by a FramebufferUpdate. That's the only way be sure that the next requested FramebufferUpdate is in the expected pixfmt, as I'm sure you understand. Hmmm, perhaps not the only way, see below... The problem is that you seem to think that this is only a problem when using the Refresh Screen function in VNC Free Edition, while my position is that it is a generic protocol problem which puts unfortunate limitations on clients. So, if the following is true: 1. the client has an outstanding FramebufferUpdateRequest 2. the client has lost its visual framebuffer 3. the client screen depth has changed (likely to cause 2) 4. the client doesn't have a backup copy of the framebuffer 5. the server doesn't have any updates for a long time then the client will show a blank screen for an indefinite period as the spec puts it. It has to wait for the server before it can refresh with the new pixfmt. I think it is very valid for the client to want to change pixfmt and get an update *now*. Sure, it can send extra non-incremntal FramebufferUpdateRequests and then try to sort out when it can be sure that no more FramebufferUpdates are coming down the wire, but that is complex. The proposed solution in my previous mail is just so much simpler, and keeps in line with implementing a client is made as simple as possible, again from the spec. Just compare to this complex alternative when you want to change pixfmt and get an update *now*: 1. Send a non-incremental FramebufferUpdateRequest for a small area. 2. Wait for a FramebufferUpdate. 3. If the update does not contain the requested area from 1, goto 7. 4. Send a non-incremental FramebufferUpdateRequest for another (non-intersecting) small area. 5. Wait for a FramebufferUpdate. 6. If the update does contain the requested area from 4, goto 8. 7. Wait for a FramebufferUpdate. 8. Send SetPixelFormat. 9. Send full non-incremental FrameBufferUpdateRequest. Is there a simpler way to work around this without protocol additions such as new pseudo-encodings? Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: pixel format is out of sync, after refreshing and suddenly changing pixel format
On Thu, Dec 13, 2007 at 12:40:11PM -, James Weatherall wrote: Peter, It is a limitation of the RFB 3.x protocol, which requires that update requests are required to be matched 1-to-1 by framebuffer updates, although this isn't strictly required if the pixel format isn't going to change. It therefore affects VNC Free Edition software based upon it. Hi Wez, Indeed, but to reiterate a previously unanswered question: When the solution is a simple as introducing a pseudo-encoding that gets sent (if requested of course) as an empty rect before any rect with the new pixfmt is sent, why not introduce that? (i.e. similar to the DesktopSize pseudo-encoding) Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: winvnc4 commandline sequence/syntax
On Tue, Dec 04, 2007 at 04:09:56PM -0800, Dave Stoft wrote: My conclusion has been that I have misunderstood the syntax or application of the syntax with the command-line method but I have been unable to locate explicit examples to show where I made the error(s). Can you point to the flaw(s) in my understanding or methodology? Thank in advance to anyone with suggestions. The command line arguments to the service is specified in the registry. You should change HKLM\System\CurrentControlSet\WinVNC4\ImagePath from the typical C:\Program Files\RealVNC\VNC4\winvnc4.exe -service to something of your liking, e.g. C:\Program Files\RealVNC\VNC4\winvnc4.exe -service -vncconfigfile C:\vnc\my_config_file.vnc (Please note that the actual executable needs to be surrounded with quotes if its path contains spaces. I don't know how you should quote spaces in the arguments, that might depend on the winvnc4 implementation.) After that, do winvnc4 -start There is no need to register/unregister around each start/stop. Disclaimer: This is all untested, but I beleive it matches what Wez said. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Inconsistent Black Screen issues...
On Mon, Aug 06, 2007 at 12:03:02AM -0400, Boyd Campbell wrote: Good evening all, I'm using VNC to connect to a specific server on a remote LAN from many different clients at many different locations. However, using the same machine on one network vs. another, I'm either able to get into the server in question fine or I get a black screen with no visual. The mouse is moving on the server and a hard connection is made, but the client only gets a black screen. IE: Using a single laptop, I can get connected instantly from one LAN with no issues, yet from another LAN, black screen. I'm also able to connect from different machines on the LAN's that work. All machines in question thus far have been XP Pro, SP2, RDP User Switching off (neither of which really matter anyways, since I am indeed able to connect using the same machine(s) from one network but not another). Also, the server in question is behind a VPN router with port forwarding to 5900 on (hence our being able to connect to begin with). I've even gone to lengths of messing with the MTU RWIN settings and used the TCP/IP Optimizer off from SpeedGuide.net...all to no avail. I've searched many lists and Google high and low for answers to this issue. As I'm sure you well know, this issue has been an issue for many years with VNC, but I haven't been able to find any definitive answers by the VNC folks or others. Most of the answers I've found were merely suggestions that appeared to be just shots in the dark (simply my perception based on verbiage). In my humble opinion, if this is to be a viable product, then this issue needs to be addressed once and for all, being put under the VNC FAQ's since it is most certainly a FAQ on every list I've found, regardless of the domain I've found the issue listed on. But I've found everything from simple answers to uber-geek answers, none of which have helped and none of which I've been able to find on the VNC site. I very humbly state, if RealVNC, Ltd. expects me, my company and my clients to drop cash for the Enterprise versions of this software, then someone needs to show me that the tool will work from anywhere around the world with an internet connection if I go with it. I'm using the free one now as a POC. But thus far, things have been problematic at best, and I've not been able to find any viable solutions from the VNC technical community at large. I would very much appreciate any help you all can lend. You say that you have played with MTU, does that include playing with the server? Did you try to disable its Path MTU Discovery which is my bet at what is wrong here (since largish amounts of data is not getting from the server to the client). Or maybe I should wager that the server (or some firewall) blocks the relevant ICMP messages needed for Path MTU Discovery... See http://www.netheaven.com/pmtu.html for some background on my wild guess. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Inconsistent Black Screen issues...
On Mon, Aug 06, 2007 at 10:48:20AM -0400, Boyd Campbell wrote: Please recall from my message that it works fine from some locations and is consistent across machines at those locations. IE: All machines at certain locations work and all machines at other locations get the black screen. I fail to see how the server is the issue, but I'm still open to your suggestions and will review the link. That behaviour is exactly the expected behaviour when the server tries to do a Path MTU Discovery but fails (in some cases.) On the working networks the MTU used by the server fits on all path components (the Path MTU Discovery is never triggered or works as expected.) On the non-functional networks the MTU used by the server triggers an ICMP request to fragment the data, but that request is dropped/filtered by some network equipment on its way back to the server. But again, I'm just guessing. Cheers, Peter Anyone else with thoughts? I'd very much like to hear from the VNC community. Thank you. -Original Message- From: Peter Rosin [mailto:[EMAIL PROTECTED] Sent: Monday, August 06, 2007 5:11 AM To: Boyd Campbell Cc: vnc-list@realvnc.com Subject: Re: Inconsistent Black Screen issues... On Mon, Aug 06, 2007 at 12:03:02AM -0400, Boyd Campbell wrote: Good evening all, I'm using VNC to connect to a specific server on a remote LAN from many different clients at many different locations. However, using the same machine on one network vs. another, I'm either able to get into the server in question fine or I get a black screen with no visual. The mouse is moving on the server and a hard connection is made, but the client only gets a black screen. IE: Using a single laptop, I can get connected instantly from one LAN with no issues, yet from another LAN, black screen. I'm also able to connect from different machines on the LAN's that work. All machines in question thus far have been XP Pro, SP2, RDP User Switching off (neither of which really matter anyways, since I am indeed able to connect using the same machine(s) from one network but not another). Also, the server in question is behind a VPN router with port forwarding to 5900 on (hence our being able to connect to begin with). I've even gone to lengths of messing with the MTU RWIN settings and used the TCP/IP Optimizer off from SpeedGuide.net...all to no avail. I've searched many lists and Google high and low for answers to this issue. As I'm sure you well know, this issue has been an issue for many years with VNC, but I haven't been able to find any definitive answers by the VNC folks or others. Most of the answers I've found were merely suggestions that appeared to be just shots in the dark (simply my perception based on verbiage). In my humble opinion, if this is to be a viable product, then this issue needs to be addressed once and for all, being put under the VNC FAQ's since it is most certainly a FAQ on every list I've found, regardless of the domain I've found the issue listed on. But I've found everything from simple answers to uber-geek answers, none of which have helped and none of which I've been able to find on the VNC site. I very humbly state, if RealVNC, Ltd. expects me, my company and my clients to drop cash for the Enterprise versions of this software, then someone needs to show me that the tool will work from anywhere around the world with an internet connection if I go with it. I'm using the free one now as a POC. But thus far, things have been problematic at best, and I've not been able to find any viable solutions from the VNC technical community at large. I would very much appreciate any help you all can lend. You say that you have played with MTU, does that include playing with the server? Did you try to disable its Path MTU Discovery which is my bet at what is wrong here (since largish amounts of data is not getting from the server to the client). Or maybe I should wager that the server (or some firewall) blocks the relevant ICMP messages needed for Path MTU Discovery... See http://www.netheaven.com/pmtu.html for some background on my wild guess. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Hitachi-ZYWRLE Encoding Number (was RE: Introduction of New VNC codec)
On Fri, Feb 02, 2007 at 12:30:49PM -, James Weatherall wrote: Hi Noriaki-san, I've had encoding number 17 allocated to Hitachi ZYWRLE - using this encoding number will ensure compatibility with standard VNC and VNC-compatible releases. The next release of the VNC codebase will therefore include an encoding place-holder: const int encoding3rdPartyHitachiZYWRLE = 17; The ZYWRLE encoding does not appear in the latest RFB spec. (Also, UltraVNC seem to experiment with encoding 9. Is that one registered?) Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Request for numbers for gii protocol extension.
Hi! I have a working version of an RFB protocol extension, one of the things missing before I publish is what numbers I should use. I need one pseudo-encoding, one server-client message and one client-server message, all can go under the name gii (General Input Interface) in the protocol spec. As you might have guessed from the name, it extends the protocol to be more flexible in the input device area, i.e. replacing (and extending) KeyEvent and PointerEvent. Basic operation: Client requests gii using the pseudo-encoding, server and client then continue to communicate using the server-client and client-server messages. So, can someone assign me some protocol numbers, please? Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Bug in the RFB spec.
On Tue, May 15, 2007 at 08:13:29AM +0700, Constantin Kaplinsky wrote: Hello Peter, Peter Rosin wrote: While implementing some vnc software I noticed a problem in the RFB spec (version 3.8, 5 October 2006). It fails to mention that there is no security result for authentication method 'None' for protocol version 3.3. As this differs from at least version 3.8 I think there should be some words on this topic in the spec. This is documented, see the page 13 of the specification: 6.2 SECURITY TYPES 6.2.1 None No authentication is needed and protocol data is to be sent unencrypted. Version 3.8 onwards The protocol continues with the SecurityResult message. Version 3.3 and 3.7 The protocol passes to the initialisation phase (section 6.3). Hi Constantin, How embarrassing. Oh well, that explains why I got it right in the server code, but didn't remember needing to work around this problem when the problem was found in my client code. Side note: a certain Windows only VNC client is a true pest when you are implementing a server and want to be compatible, that for sure took some workarounds (Oh great, you can do 3.8, then I want 3.4, oh and 3.4 means that I will do this and that and whatnot. What crap). The companion server in said VNC suite is more friendly. How do other true VNC servers handle this rouge client? Anyway, thanks for the pointer. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Bug in the RFB spec.
On Tue, May 15, 2007 at 11:00:00AM +0100, James Weatherall wrote: Peter Rosin wrote: Side note: a certain Windows only VNC client is a true pest when you are implementing a server and want to be compatible, that for sure took some workarounds (Oh great, you can do 3.8, then I want 3.4, oh and 3.4 means that I will do this and that and whatnot. What crap). The companion server in said VNC suite is more friendly. How do other true VNC servers handle this rouge client? The only valid RFB protocol versions at present are 3.3, 3.7, 3.8 and 4.0, so the VNC viewer that you're referring that reports RFB 3.4 isn't actually VNC-compatible. I know, but e.g. the RealVNC free edition server 4.1.2 doesn't bail when a (broken) client requests 3.4, I was wondering if it did anything else to accomodate the (broken) client than treat it as if 3.3 had been requested? Any pointers to where (when perhaps?) I can find the 4.0 spec? Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Bug in the RFB spec.
Hi list! While implementing some vnc software I noticed a problem in the RFB spec (version 3.8, 5 October 2006). It fails to mention that there is no security result for authentication method 'None' for protocol version 3.3. As this differs from at least version 3.8 I think there should be some words on this topic in the spec. The above is the behaviour I'm observing when connecting to a RealVNC 4.1.2 server, and I assume that it's the spec that's in error. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: How to restore the session if vnc server is configure as daemon mode xinetd
On Fri, Feb 16, 2007 at 11:22:45AM +0100, Corne Beerse wrote: Dhillon, Gurjit wrote: I have set up vnc as a daemon mode through xinetd, it is working fine. Great. User give ipaddress and the predefined port number to connect the vnc server. The only difference is now user doesn't need to login the Linux server and generate the port number to connect the server through vnc, now it is asking for login and password to connect the server. But here if user close the session after login or after his job done, and want to work in the same session after some day or some time, they are not able to do that. Thats one of the nice features of inetd (or xinetd): As soon as the connection ends, the processes are cleared. If you want re-entrant vnc-sessions, you cannot use inetd or xinetd. Bzzt, not entierly true. You should investigate the wait option of inetd (wait = yes for xinetd). It is very possible to have a server controlled by (x)inetd survive a disconnected connection. That said, I don't know if any vnc server actually supports this mode of operation, but I'd be surprised if they didn't. [snip] Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: Proposed new encoding: bz2tile
On Thu, Feb 15, 2007 at 01:03:24PM -0600, Matt Campbell wrote: Hello James: I have implemented the encoding, and so far, it seems to work well, though I'll admit I'm testing on fast CPU's (at least 2 GHz). Please allocate an encoding number for this encoding. Also, a clarification on this encoding: Unlike ZRLE, a bz2tile rectangle does not start with a length field on the wire. Instead, each bz2tile rectangle is represented on the wire by a complete bzip2 stream. But then you lose the dictionary (or equivalent), and the compression ratio suffers, no? This works because libbz2 can identify the end of a bzip2 stream and indicate to the caller how many bytes of input were left unused. It does mean that a bz2tile rectangle requires at least 37 bytes, but the server could avoid excess overhead by using hextile for rectangles under a certain size. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: About single application RFB server
On Mon, Jan 29, 2007 at 10:11:20AM +0800, lizhong wrote: Peter Rosin wrote: [1] http://www.ggi-project.org/documentation/libggi/current/display-vnc.7.html [2] http://www.ggi-project.org/ [3] http://sourceforge.net/cvs/?group_id=16307 It's strange that the first two web links in your email seems unusable. They work just fine for me. Anyway, here are alternatives: http://www.ibiblio.org/ggicore/documentation/libggi/current/display-vnc.7.html http://www.ibiblio.org/ggicore/ BTW, display-vnc will not be part of any GGI 2.x release. It's destined for the upcoming GGI 3.x. I have found some information about GGI project through google, and I found this VNC LibGGI target - allows LibGGI applications to display over the network using the VNC protocol. Needs porting from old LibGGI. That's a reference to the old (unmerged) code from Steve Cheng that I mentioned. I don't even know where to find it, that's probably a dead end. Cheers, Peter ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
Re: About single application RFB server
On Fri, Jan 26, 2007 at 05:44:40PM +0800, lizhong wrote: Hi all, As we know, vnc is used to send desktop to a client from the server. I've dig into the emails of vnc mail list, and found a single application vnc server called VNC CD Player. This program was never published, and I just know that it provides remote CD Player interface using RFB protocol. Is there any ready-made VNC server which could allow the user to select a remote appliction, and transmit not the whole desktop but only the interface of this appliction? Thanks for any help! I have written an RFB/VNC backend [1] for libggi [2]. So any decently well-written GGI application should be able to act as a single application VNC server. There is a caveat though, and that is that the VNC backend is only in the CVS version [3] of libggi, and the release including it is probably not going to happen anytime soon. So, you will have to do some compiling yourself to get going. I know there was once another such backend written by Steve Cheng which was based on the RealVNC code base, but that work was never merged due to license incompatibilities. This backend has been written from scratch to evade the license incompatibility (BSD vs. GPL). Cheers, Peter [1] http://www.ggi-project.org/documentation/libggi/current/display-vnc.7.html [2] http://www.ggi-project.org/ [3] http://sourceforge.net/cvs/?group_id=16307 ___ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
