> -----Original Message-----
> From: Rudi De Vos [mailto:[EMAIL PROTECTED]]
>
> It's a problem of client AND server.
> The server check resize and terminates connection with client.
> KILLLLLLLLLL
Termination by the server: WHy? Can it be removed?
>
> SERVER PROBLEM
> // Check that the screen info hasn't changed
> log.Print(LL_INTINFO, VNCLOG("SCR: old screen
> format %dx%dx%d\n"),
> oldscrinfo.framebufferWidth,
> oldscrinfo.framebufferHeight,
> oldscrinfo.format.bitsPerPixel);
> log.Print(LL_INTINFO, VNCLOG("SCR: new
> screen format %dx%dx%d\n"),
> m_desktop->m_scrinfo.framebufferWidth,
> m_desktop->m_scrinfo.framebufferHeight,
>
> m_desktop->m_scrinfo.format.bitsPerPixel);
> if (memcmp(&m_desktop->m_scrinfo,
> &oldscrinfo, sizeof(oldscrinfo)) != 0)
> {
> m_server->KillAuthClients();
> <-------------KILLLLLLLL
> break;
> }
What if you remove this?
>
> CLIENT PROBLEM
> remove the scrinfo check, recompile and test -> client crash
> because he can not handle framebuffer changes.
Why not? Does it get any?
>
> You need to do something like this on server site.
>
> rfbScreenFormatUpdateMsg ScreenFormatUpdate;
> <----------------NEW RFB protocol
> ZeroMemory(&ScreenFormatUpdate, sz_rfbScreenFormatUpdateMsg);
> screenFormatUpdate.type = rfbScreenFormatUpdate;
> ScreenFormatUpdate.width = newwidth;
> ScreenFormatUpdate.height = newheight;
> ScreenFormatUpdate.format = m_desktop->m_scrinfo.format;
> m_server->UpdateScreenFormat(ScreenFormatUpdate);
> m_server->UpdateRect(rect);
> m_server->UpdatePalette();
>
> Perhaps this can also be done using a full reinitialization.
> But client and server need to be changed and an rfbprotocol need to
> tell the server that the client support the resizing.
What if the server just does a full reinitialization to current viewers? If
it's a crash, the user does not see anything different than a kill, it's
just an other 'end-of-the-action'.
After a geometry change, the entire display needs to be redrawn and much
more like that.
>
> Perhaps it is already include in RFB 4.0.
> Need to check it!
>
> <<<As long as the protocol is not broken, the multi platform
> is no problem: it
> <<<cannot get worse than a broken connection as it is now. A
> new server with an
> <<<old viewer will crash as it does now, an old server with a
> new viewer might
> <<<crash as it does now.
> As you see in the code, it is No Crash, but a killclient of
> the server. Removing this part
> lead to a situation. New server realy crash old clients
> "memory assertion errors" !!!!
>
> The rfbprotocol need to be adapted to allow doing desktop resize.
Since a resize most likely includes full screen update, why not a full
reinitialize?
>
> Greetings
> Rudi
Don't feel atacked, I'm just viewing the problem from a long distance and
don't like to come close to see the gory details. My general remark here is
'can you coop with wath you have?, even if it is somehow limited?' and from
my years in unix programming, I've learned that removing checks sometimes
imporves the usability.
A silly example I sometimes use here is the next software requirements:
If the input 2 is given, then the result must be 4. If the input 4 is given,
then the result must be 16.
General solution, just writing the requirements:
if input == 2
then result = 4
else if input == 4
then result = 16
else ERROR
A solution with a little more thinking:
result = input * input
Both solutions do exactly as asked but the last one has a much wider usage.
Lesson learned: remove unnecesary checks by using the proper routine.
CBee
>
> -----Original Message-----
> From: "Beerse, Corni" [mailto:[EMAIL PROTECTED]]
> Sent: donderdag 13 juni 2002 15:28
> To: '[EMAIL PROTECTED]'
> Subject: RE: RFB protocol
>
>
> > -----Original Message-----
> > From: Rudi De Vos [mailto:[EMAIL PROTECTED]]
> > The problem is not implementing the option.
> > Just a few changes on server and client site.
> > But changing the client, is loosing compatibility...
> > Rewriting the client for all platforms.
> >
> > The resizing stuff was implemented in the old Single shared
> > application
> > code. Resizing the application sends an rfb messages to the
> > client....
> > (Application or desktop...internal it is just the same code)
> > Because a special client was needed, I left the idea ...
>
> Was this your idea for single shared application or was it in
> previous vnc
> versions?
>
> What message is send at the moment the viewer starts? Then it
> gets a message
> including the size and colordepth. The server should send
> this again, with
> the new information. What happens if the viewer receives that
> message again,
> with the new size and colordept? If it is the viewer that
> collaps, then the
> viewer needs an update at this point.
>
> The java viewer has a problem here: the applet gets a
> viewport based on the
> initial size which cannot be resized. This java viewer should
> add borders
> for smaller displays and go in a panning mode for larger displays.
>
> >
> > Unless the majority of developpers agree to implement this option,
> > it stays a part of the wishlist.
> >
> > Perhaps we can start a discussion in a whishlist thread and try
> > to make a priority list....keeping in mind that all have to
> > be cross platform and technical possible.
>
> As long as the protocol is not broken, the multi platform is
> no problem: it
> cannot get worse than a broken connection as it is now. A new
> server with an
> old viewer will crash as it does now, an old server with a
> new viewer might
> crash as it does now.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >
> > Are there any plans to update the RFB protocol support things like
> > resoloution and colour depth switching? And other
> limitiations of the
> > current system?
>
> It should not need an update, just a resend of the initial message.
>
> >
> > It's quite annoying when a app changes the desktop
> resolution, and VNC
> > dumps out.
>
> If this connection close is issued from the server, I regard
> it as a design
> problem which should be updated to a re-initialization of the
> connection.
>
> If this connection close is issued from the viewer, it only
> needs a rewrite
> of the viewer.
>
>
> btw: What if the vnc connection is established with the
> listen option? Does
> this also drop connections?
>
>
>
> CBee
> _______________________________________________
> VNC-List mailing list
> [EMAIL PROTECTED]
> http://www.realvnc.com/mailman/listinfo/vnc-list
> _______________________________________________
> VNC-List mailing list
> [EMAIL PROTECTED]
> http://www.realvnc.com/mailman/listinfo/vnc-list
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list
