Igor:
You're right that VNC server discovery, particularly
in Win98, has become less reliable. As Jeff suggested, it may
be interesting to try a heap walker or bound checker to see if
we can isolate the cause.
On a related subject, I was hoping you could modify
the behavior of the "log VNC usage" button. Right now all it
does is set the registry entry for WinVNC. Problem is, when
I hit "View Log" it never finds the file, I always have to
browse for it. I was hoping you could do one of two things:
1. Have the WinVNC log be written into the installation dir,
and have ViewLog always look there first.
2. Alternatively, don't use WinVNC log at all. Kaboodle has
its own debug info now that's written to VncServerSessionLog
when built in Debug mode. Perhaps we could output some (not
all) of that info into a .txt file.
The intent with logging was for the user to be able to
find out who connected, or tried and failed to connect, to their
VNC server. All it needs to show are timestamps, IP address of
the Viewer, and connection status (failed, connected, disconnected,
etc). Unfortunately, the debug info shows a whole lot more than
just that.
Perhaps we could combine both: if the user has "Log
VNC usage" we could both set the debug flag in the VNC registry,
*and* record Kaboodle-detected info. So if someone connected
directly, we could show that from grep'ing the VNC log file.
If someone connected via Kaboodle, we could show that directly.
Eager for your thoughts. I suppose getting #1 to work
above would be sufficient for the needs of 0.90.
-Scott
On Wed, 14 Aug 2002, Igor Kotelevsky wrote:
> Hello Scott.
> I see that VNC server discovery has become less reliable.
> That unreliability shows itself in release build, particularly in Win98 OS.
> It isn't possible that one of my recent updates broke something -
> I didn't changed something pertaining to that part.
> Here is what I have found.
> Now VNC discovery sometimes cannot create a client socket for scan port.
> I see the system error's code 10055.
> That error has following text
> "An operation on a socket could not be performed because
> the system lacked sufficient buffer space or because a queue was full".
> It looks like another thread simultaneously makes big lot of socket work.
>
> Here is what I can implement for the button "Check Again" only.
> If VNC server discovery receives above error code 10055,
> then it waits 0.3 second and repeats the operation one more time.
> It seems to me that the button "Check Again" will be more reliable.
>
> I cannot implement above check error code 10055 for VNC server discovery
> at the first start Kaboodle (empty registry setting).
> It seems to me that it is uselessly in that case.
> We have to find and fix the reason of error code 10055.
>
> - Igor
>
> ----- Original Message -----
> From: "Scott C. Best" <[EMAIL PROTECTED]>
> To: "Igor Kotelevsky" <[EMAIL PROTECTED]>
> Cc: "Kaboodle-devel" <[EMAIL PROTECTED]>
> Sent: Wednesday, August 14, 2002 8:37 AM
> Subject: Re: [Kaboodle-devel] Release build problem
>
>
> > Igor:
> > Your changes look good. I noticed one thing though: it
> > seems as if the VNC server discovery has become less reliable
> > since you made these changes. Sometimes it takes two or three
> > "Check Again" tries for it to find the VNC server one one of
> > my machines. It used to catch it right away.
> >
> > This is in release build, latest stuff. Is it possible
> > that one of the recent updates broke something?
> >
> > -Scott
> >
> > On Tue, 13 Aug 2002, Igor Kotelevsky wrote:
> >
> > > Hello Scott.
> > >
> > > I inserted exact your texts
> > > into the top of "VNC setup" tab in the device icon.
> > > Now only the "Check Again" button is active
> > > if VNC connection is not possible.
> > >
> > > Also I found that Kaboodle saves special debug data into the log files
> > > - KaboodleNIDPreAlpha.xml,
> > > - Kaboodle_Dbg.htm,
> > > - Gnutella.log.
> > > That files appeared both in debug and release builds.
> > > Now that files appear in debug build only.
> > >
> > > - Igor
> > >
> > > ----- Original Message -----
> > > From: "Scott C. Best" <[EMAIL PROTECTED]>
> > > To: "Igor Kotelevsky" <[EMAIL PROTECTED]>
> > > Cc: "Kaboodle-devel" <[EMAIL PROTECTED]>
> > > Sent: Tuesday, August 13, 2002 8:28 AM
> > > Subject: Re: [Kaboodle-devel] Release build problem
> > >
> > >
> > > > Igor:
> > > > Good, thanks; VNC tunneling is working again nicely.
> > > > Only bug I can find right now: when I'm on PC1 and I open the
> > > > device icon for PC2 (which is not running a VNC service) it
> > > > says at the top "when connecting to <b>PC2</b> from <b>PC1></b>
> > > > use these settings". It *used* to say "PC2 is not running a
> > > > VNC Service" and only the "Check Again" button was active.
> > > > Did that get changed somehow?
> > > >
> > > > -Scott
> > > >
> > > > On Mon, 12 Aug 2002, Igor Kotelevsky wrote:
> > > >
> > > > > Hello Scott.
> > > > > I found next VNC problem:
> > > > > - PC1 run independent VNC service;
> > > > > - PC1 run Kaboodle with option "Enable Kaboodle Tunnels for VNC";
> > > > > - I open PC1 device icon on PC2 machine and
> > > > > try to start up "Connect through Kaboodle". That connection failed.
> > > > > I found conflict in port number:
> > > > > - independent VNC service on PC1 listen some port number.
> > > > > That number by default is 5900.
> > > > > (it is number by default);
> > > > > - Kaboodle on PC1 reads port number of VNC viewer and
> > > > > uses it for start up VNC viewer,...
> > > > > That number by default is 5900 also.
> > > > > Now that bug fixed.
> > > > > Before start "Connection through Kaboodle"
> > > > > Kaboodle on the viewer side make check:
> > > > > if there is running independent VNC server on the port number
> > > N_VNC_SERVER,
> > > > > then port for start VNC viewer cannot be same as N_VNC_SERVER
> > > > > and same as port, which use for tunnel.
> > > > >
> > > > > I continue test Kaboodle in release and debug mode.
> > > > > I see that Kaboodle works both in release and debug mode.
> > > > > If you will find any VNC bug, please send me next log files
> > > > > - SessionVncServerLog.txt,
> > > > > - SessionVncViewerLog.txt,
> > > > > - ViewerThreadLog.txt
> > > > > for both Kaboodles.
> > > > >
> > > > > About port number 7000.
> > > > > Kaboodle always listens TCP connection on port number 7000.
> > > > > Please see
> > > > > http://www.geocrawler.com/archives/3/16728/2002/5/0/8657977/
> > > > > If PC1 need to start independent VNC server on PC2,
> > > > > then PC1 send special message to the PC2 on port number 7000.
> > > > > Also that port used for initialization "File Transfer".
> > > > >
> > > > > - Igor
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Scott C. Best" <[EMAIL PROTECTED]>
> > > > > To: "Igor Kotelevsky" <[EMAIL PROTECTED]>
> > > > > Cc: "Kaboodle-devel" <[EMAIL PROTECTED]>;
> "mailbox"
> > > > > <[EMAIL PROTECTED]>
> > > > > Sent: Sunday, August 11, 2002 9:17 PM
> > > > > Subject: Re: [Kaboodle-devel] Release build problem
> > > > >
> > > > >
> > > > > > Igor:
> > > > > > I agree that the Release builds are not working right
> > > > > > now. However, even in Debug mode, I cannot get VNC tunneling
> > > > > > to work anymore. So I used WinCVS to get a code snapshot from
> > > > > > August-8, so that VK's NID-synch bugs were not involved. Still
> > > > > > doesn't work. Details:
> > > > > >
> > > > > > 1. I'm running the VNC server on PC1, WinNT, debug build.
> > > > > > No VNC service is active, Kaboodle is setup to "autostart if
> > > > > > needed". On PC2, running Win2k, in the Device Icon for PC1, in
> > > > > > the VNC Setup tab, "Connect Directly" is greyed out. Since
> > > > > > no server is running on PC1, both choices should be active.
> > > > > >
> > > > > > 2. Then on PC2 I open the VNC Service Icon, and go to the
> > > > > > list of viewers. I enter the password for PC1, hit connect. I
> > > > > > immediately get an error from VNC "Cannot connect to server".
> > > > > > Over on PC1, the VNC server icon is in my service tray, and
> > > > > > it's lit-up, indicating it's receiving a connection. The log
> > > > > > file on PC1 has just two lines: "BEGIN: StartVNCServer" and
> > > > > > "StartVNCServer: Ok start Independent VNCserver port number
> > > > > > 5900". I look at the tcpdump traffic on my LAN, and see the
> > > > > > following. When I hit connect:
> > > > > >
> > > > > > 16:36:57.351343 192.168.123.134.1189 > 192.168.123.130.7000: S
> > > > > > 2008127198:2008127198(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
> > > > > >
> > > > > > In the above, PC1 is .130 and PC2 is .134. Why would port
> > > > > > 7000 be involved in a VNC tunnel? I wait a few seconds to see
> which
> > > > > > port the VNC viewer on PC2 is trying to use. Keep in mind that
> > > > > > "Connect Directly" was not a valid choice:
> > > > > >
> > > > > > 16:36:57.807921 192.168.123.134.1190 > 192.168.123.130.5900: S
> > > > > > 2008283092:2008283092(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
> > > > > >
> > > > > > So PC2 has tried to connect directly, even though
> > > > > > Kaboodle on PC1 has opened a tunnel and connected successfully
> > > > > > with the VNC server (which is why the VNC icon in the service
> > > > > > tray is lit-up bright white).
> > > > > >
> > > > > > 3. I then try connecting again from PC2. I get a Kaboodle error
> > > > > > saying "You already have a VNC session connected with PC1".
> > > > > >
> > > > > >
> > > > > > Thanks for looking into this. I was very surprised that
> > > > > > port-7000 got involved with this connection attempt.
> > > > > >
> > > > > > -Scott
> > > > > >
> > > > > >
> > > > > > On Fri, 9 Aug 2002, Igor Kotelevsky wrote:
> > > > > >
> > > > > > > Hello Scott.
> > > > > > > I have tested all my changes in both debug and release builds.
> > > > > > > All worked.
> > > > > > > Then I merged my code with CVS code.
> > > > > > > Now Kaboodle works in debug builds only.
> > > > > > > There is a problem in realise build -
> > > > > > > Kaboodle starts, but a user don't see GUI.
> > > > > > > I found a problem.
> > > > > > > Please look into the function int CEFController::Start().
> > > > > > > There is a line
> > > > > > > while (!m_pNetworkManager->bStartUpFinished);
> > > > > > > It seems to me that there is infinite loop in realize build.
> > > > > > > The member m_pNetworkManager->bStartUpFinished
> > > > > > > sets as "TRUE" in the function
> > > > > > > int CNetworkManager::OnStartup(DWORD nIDController, CGUID
> > > KaboodleID).
> > > > > > > It seems like that function don't works correctly in release
> build.
> > > > > > >
> > > > > > > - Igor
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------
> > > > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > > > Welcome to geek heaven.
> > > > > > > http://thinkgeek.com/sf
> > > > > > > _______________________________________________
> > > > > > > Kaboodle-devel mailing list
> > > > > > > [EMAIL PROTECTED]
> > > > > > > https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
