Termination by the server: WHy? Can it be removed? If I remember correct, not only the client crash, but also the server... So you can not reconnect and have to go to the server to restart winvnc, not easy when you work remote. A changed version of server and viewer will be on my site end this weekend. Just a few tweaks of the current code and an a little change to the rfbproto. /* server -> client */ #define rfbScreenFormatUpdate 4
/* Union of all server->client messages.*/ typedef union { ... rfbScreenFormatUpdateMsg sfu; } rfbServerToClientMsg; Vnc wasn't written to allow screen changes, remote audio and file transport support etc... Adding some extra option to vnc mostly means adding some extra rfbcodes in the rfbproto. (look at the addons you find on the old at&t site) Because this has an impact on future versions, there need to be a new rfb+ guideline. sample: Jan create a new encoder with number PngEncoder 100 Piet create a Black&WithEncoder with number 100 There have to be some new rules for making changes to the rfbproto file. A little remark about removing checks! When you create an application for a customer, with a popup telling "this operation is not allowed", he knows the program wasn't written for it. But when a program crash on an action, he complain the program is not working and want a fix for it. Unix is a lot more robust. Application run in there own protected environment. A unix program crash just stop the current program without any impact on the OS. Windoz is not that secure, unpredicted program crashes can crash the whole OS and start eating your memory. When winvnc server or client crash, the memory don't go back in the pool, but is lost until reboot. Better sending a kill and closing proper the application. When you need to reboot your unix box, you also make a proper shutdown. Why not just pulling the plug ??? Greetings Rudi -----Original Message----- From: "Beerse, Corni" [mailto:[EMAIL PROTECTED]] Sent: vrijdag 14 juni 2002 10:36 To: '[EMAIL PROTECTED]' Subject: RE: RFB protocol > -----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 _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list