Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Repeater hangs
Repeater hangs
Hi everybody,
I'm using SC or "Add new client with ID code" with WinVNCsc 20.3, WinVNC 1.0.1 and Repeater 1.0.4.
Very often after a period of correct functionality the repeater stops accepting server connections, i.e. in the logs I see only
accept() connection
Viewer added to list 9999
but not
Server added to list 9999
without any errors. Restarting the repeater solves this problem.
What can this be?
BTW: what about source code of the repeater?? if this was available I could add some debug info myself...
Thanks
Davide
I'm using SC or "Add new client with ID code" with WinVNCsc 20.3, WinVNC 1.0.1 and Repeater 1.0.4.
Very often after a period of correct functionality the repeater stops accepting server connections, i.e. in the logs I see only
accept() connection
Viewer added to list 9999
but not
Server added to list 9999
without any errors. Restarting the repeater solves this problem.
What can this be?
BTW: what about source code of the repeater?? if this was available I could add some debug info myself...
Thanks
Davide
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Sources are on soureforge
http://sourceforge.net/project/showfile ... p_id=63887
Please let us know if you find the bug...
The problem is that it does not happen a lot of times, making it hard to debug.
You need to see what happen before block ( possible you need to add a lot of comments and write it to a file)
http://sourceforge.net/project/showfile ... p_id=63887
Please let us know if you find the bug...
The problem is that it does not happen a lot of times, making it hard to debug.
You need to see what happen before block ( possible you need to add a lot of comments and write it to a file)
Repeater hangs
After some days of testing with a modified repeater with added debug infos, I can't still find the problem... after some connections it seems that the repeater does not accept server connections anymore on port 5500; the port is open, but for example trying to connect to the repeater with netcat with "nc server 5500" it returns immediately instead of waiting for input (like the normal situation).
Using procexp I saw that the repeater is listening to 5500 and the listening thread is open; I added a debug message "server accept" in the else part just after the
connection = accept( sock, &client, &socklen);
but I don't get any message, accept nor error!
Any help is appreciated...
...but I don't understand why I am the only one having this problem!
Thanks
Davide
Using procexp I saw that the repeater is listening to 5500 and the listening thread is open; I added a debug message "server accept" in the else part just after the
connection = accept( sock, &client, &socklen);
but I don't get any message, accept nor error!
Any help is appreciated...
...but I don't understand why I am the only one having this problem!
Thanks
Davide
My repeater stops responding too.
I have previously reported this problem but no-one responded to my message. I resorted to creating a schedule that stops and starts the repeater service periodically. Sorry I can't help you but rest assured you are not the only one that is having the problem. Thanks for putting in the effort in trying to identify the problem. I'm using repeater version 1.1.0.4
Repeater hangs
Glad to see I'm not the only one...
This is a very BIG problem with the repeater use, and appears so frequently that solving it is a MUST.
Instead on focusing on NAT2NAT, SCiii etc etc why not focusing on making the basic things more reliable?
Any help on debugging/solving this issue is kindly appreciated (ehi Rudi!!!)
Thanks everybody
Davide
This is a very BIG problem with the repeater use, and appears so frequently that solving it is a MUST.
Instead on focusing on NAT2NAT, SCiii etc etc why not focusing on making the basic things more reliable?
Any help on debugging/solving this issue is kindly appreciated (ehi Rudi!!!)
Thanks everybody
Davide
Repeater hangs - SOLVED
Hi all,
I have solved the problem of the repeater (at least for now and at least for me...). I found that the repeater was not accepting connections anymore when a client (be winvnc or vncviewer) remain stuck just after establishing a connection and the repeater remains blocked while recv'ing the ID:xxxx; since the listen was used with a backlog of 1, the connection in immediately refused for all next releases.
I solved specifying a timeout with SO_RCVTIMEO and SO_SNDTIMEO before the ReadExact.
If someone is interested I can send the code and/or the exe by email (I don't a permanent IP address).
I also added some other useful info (active connections monitoring, better logging system, ecc...)
Bye
Davide
I have solved the problem of the repeater (at least for now and at least for me...). I found that the repeater was not accepting connections anymore when a client (be winvnc or vncviewer) remain stuck just after establishing a connection and the repeater remains blocked while recv'ing the ID:xxxx; since the listen was used with a backlog of 1, the connection in immediately refused for all next releases.
I solved specifying a timeout with SO_RCVTIMEO and SO_SNDTIMEO before the ReadExact.
If someone is interested I can send the code and/or the exe by email (I don't a permanent IP address).
I also added some other useful info (active connections monitoring, better logging system, ecc...)
Bye
Davide
I would like your modified repeater.exe please.
I'm glad you found a way to make the repeater more reliable. Could you email the exe to repeater@email.com . I'll keep you posted as to how I make out with your version.
Thanks,
Joe
Thanks,
Joe
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Hi Davide,
Could you please send me the updated .exe? It would be greatly appreciated.
vnc@bitspy.com
Thanks
Could you please send me the updated .exe? It would be greatly appreciated.
vnc@bitspy.com
Thanks
Last edited by TalynOne on 2005-12-22 06:59, edited 1 time in total.
Can you send it to me at simon.hamiltonREMOVECAPS@ntlworld.com anyway, so i can have a look. I've only been playing mostly with the new betas with SSL support but am keen to see the new features you've added._Ghost_ wrote:No it is a slightly modified version of the 1.1.0.4 version, for use with "Add new client" with ID code and/or SingleClick V1.
Thanks
--
Simon H
Would appreciate a copy here..
I have the same problem... would appreciate a copy... I could even host it on a website for others to download. send to pwsmithATgmail . c o m .
Thanks!
Thanks!
Could you update CVS file instead of send as private message to everybody ?_Ghost_ wrote:if someone is interested I can send the code and/or the exe by email
so developer(s) can update new repeater from 1.0.4 -->1.0.5 ?
that would be more open source and available exe for non developers !
thank you a lot for your time and finding bug and added fix
(I don't see it because I don't have the repeater.exe 1.0.4 with your fix aka 1.0.5)
Would be "easy" to be ported to repeater_ssl 1.0.5 ??
Last edited by redge on 2005-12-23 00:05, edited 2 times in total.
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
CVS update
Yes obviously it would be a good thing...
I'm not am UltraVNC developer but if some of them is interested I can of course send them my patch so it can updated in the CVS, even if I think it would be better to let other some people test it before it is commited to CVS.
I have never used or seen the code of repeater_ssl so I do know about it.
Bye
Davide
I'm not am UltraVNC developer but if some of them is interested I can of course send them my patch so it can updated in the CVS, even if I think it would be better to let other some people test it before it is commited to CVS.
I have never used or seen the code of repeater_ssl so I do know about it.
Bye
Davide
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
I will check the code again, a waiting readexact should not be able toI solved specifying a timeout with SO_RCVTIMEO and SO_SNDTIMEO
block.
Each viewer/server connection have his own thread and run independed, but possible we do a ReadExact
before we fork them in the thread, causing next connections being refused.
Thanks, you are the FIRST that actual report back some fixes.
We had a lot of mails in the past, for requesting to release the source code...we did.
But if feedback stay this low, we possible will NOT release the source code of future versions.
I just wondering what the other 2000 people are doing with it
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Indeed,
after
we shoud start a seperate thread and not after read/write.
A single connection can lock the whole repeater to accept new connections.
Thanks,
I never would found this concept error.
after
Code: Select all
connection = accept( sock, &client, &socklen);
A single connection can lock the whole repeater to accept new connections.
Thanks,
I never would found this concept error.
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Update (test)
http://sc.uvnc.com/V2
distributer_105.exe
Changes:
After accept, a new thread is started. (server and viewer part)
loop
{
accept
viewer thread
}
The only thing that can happen is that the thread hang, but the repeater does not block the next accept.
I current didn't touched the SO_RCVTIMEO and SO_SNDTIMEO parameters. Changing the parameters will also have an impact on the time the viewer can wait for a server connection. Some people connect there viewer for hours and let them just waiting until the server connect.
I can hard reproduce the hang problem, so some feedback will be appriciated. (possible some other bugs where added, 5 minute code change)
http://sc.uvnc.com/V2
distributer_105.exe
Changes:
After accept, a new thread is started. (server and viewer part)
loop
{
accept
viewer thread
}
The only thing that can happen is that the thread hang, but the repeater does not block the next accept.
I current didn't touched the SO_RCVTIMEO and SO_SNDTIMEO parameters. Changing the parameters will also have an impact on the time the viewer can wait for a server connection. Some people connect there viewer for hours and let them just waiting until the server connect.
I can hard reproduce the hang problem, so some feedback will be appriciated. (possible some other bugs where added, 5 minute code change)
source code of repeater and repeater_ssl:_Ghost_ wrote:I have never used or seen the code of repeater_ssl so I do know about it.
http://sourceforge.net/project/showfile ... _id=362112
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
If you change the SO_RCVTIMEO and SO_SNDTIMEO parameters just after the accept() you change the maximum time the repeater can wait to receive the ID:xxx string, that should be immediate if everything goes ok.
It does not have anything to do with the maximum time that the viewer can wait for server connections, that is regulated by the timer thread (if I rememeber 5 mins?).
Using SO_RCVTIMEO and SO_SNDTIMEO you are sure to delete "blocked" connections instead of leaving around blocked threads.
I think that the perfect solution would be spawn a thread as you said AND set the timeouts in the new thread, so you can delete it if it is blocked.
Thanks
Davide
It does not have anything to do with the maximum time that the viewer can wait for server connections, that is regulated by the timer thread (if I rememeber 5 mins?).
Using SO_RCVTIMEO and SO_SNDTIMEO you are sure to delete "blocked" connections instead of leaving around blocked threads.
I think that the perfect solution would be spawn a thread as you said AND set the timeouts in the new thread, so you can delete it if it is blocked.
Thanks
Davide
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Correct.....seems i don't know my own code anymore
This happen when you leave it alone for a few months.
The test
http://sc.uvnc.com/V2/
distributer_107.exe
Span thread and change default timeouts to 10 min.
The default value was unacceptable high (2000 minutes)
The timeout value is less important as the only goal is to cleanup
a hung thread. A hung thread use about 10k mem and no cpu, so
if some unecpected thing happen, we can easy increase it to an hour
[mod=2,1137322915]Corrected the URL[/mod]
This happen when you leave it alone for a few months.
The test
http://sc.uvnc.com/V2/
distributer_107.exe
Span thread and change default timeouts to 10 min.
The default value was unacceptable high (2000 minutes)
The timeout value is less important as the only goal is to cleanup
a hung thread. A hung thread use about 10k mem and no cpu, so
if some unecpected thing happen, we can easy increase it to an hour
[mod=2,1137322915]Corrected the URL[/mod]
distributer_106.exe as SYSTEM mode crash
szAppName : distributer_106.exe szAppVer : 1.1.0.4
szModName : distributer_106.exe szModVer : 1.1.0.4 offset : 000029d1
socket() initialized
bind() succeded to port 5901
listen() succeded
socket() initialized
bind() succeded to port 5501
listen() succeded
accept() connection
Viewer added to list 7890
Server added to list 7890
log of distributor do not help anything
LAN: winvnc 1.0.1 192.168.1.32:5501(6 oct 2005)--> distributer_106
EDGE: vncviewer14BETA myhost.dyndns.org:5901--> distributer_106
error reported by vncviewer14BETA
rdr::Exception (2): rdr::SystemException: read: Unknown error (10054)
error reading protocol version: rdr::SystemException: read: Unknown error (10054)
szAppName : distributer_106.exe szAppVer : 1.1.0.4
szModName : distributer_106.exe szModVer : 1.1.0.4 offset : 000029d1
socket() initialized
bind() succeded to port 5901
listen() succeded
socket() initialized
bind() succeded to port 5501
listen() succeded
accept() connection
Viewer added to list 7890
Server added to list 7890
log of distributor do not help anything
LAN: winvnc 1.0.1 192.168.1.32:5501(6 oct 2005)--> distributer_106
EDGE: vncviewer14BETA myhost.dyndns.org:5901--> distributer_106
error reported by vncviewer14BETA
rdr::Exception (2): rdr::SystemException: read: Unknown error (10054)
error reading protocol version: rdr::SystemException: read: Unknown error (10054)
Last edited by redge on 2005-12-24 17:50, edited 2 times in total.
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
http://sc.uvnc.com/V2
distributer_107.exe
This one should be better...events added to wait until copy done (µs)
distributer_107.exe
This one should be better...events added to wait until copy done (µs)
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact: