Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gaznevada]

Hi all,

just a remark, I'm not so sure whether it's actually a bug or not. Anyway...

I run an "amuled" server on a remote machine. Connections to the server are made by a local
client (remote: a dialect of UNIX, local: WinXP).

From time to time local client takes quite a bit to react, two or three minutes,
may be more... after a while, if still not responding, I usually kill the client with WinXP TaskManager.

Giving the client another try, normally I'm more lucky and I get connected but
sometimes client is stubborn, not reacting at all even after several attempts to
get a response from the server.

In that unlucky cases I log on the server side then issuing an "amulecmd" command,
trying to connect to the daemon. Well, "amulecmd" goes in timeout without any connection.
It's clear (?) that the daemon is refusing to accept external connections, for some reason.

In such a case, issuing a "ps -elf" to take a look on the running process', I can notice a lot
of <defunct> process' and, not surprisingly, all of them children of "amuled".  Spooky.

Changelog of 2.2.3 says that some modifications were made in EC routines so I made
a comparison between two files, RemoteConnect.cpp versions 2.2.2 (left hand side) and 2.2.3
(rhs):

104,110c104
<    if ( !ConnectSocket(addr) ) {
<       return false;
<    }
<    
<    // if we're using blocking calls - enter login sequence now. Else,
<    // we will wait untill OnConnect gets called
<    if ( !m_notifier ) {
---
>    if (ConnectSocket(addr)) {
114c108
<    } else {
---
>    } else if (m_notifier) {
115a110,111
>    } else {
>       return false;
117c113
<    
---
>
133c129
< void CRemoteConnect::OnClose() {
---
> void CRemoteConnect::OnLost() {
139,140d134
<    // FIXME: wtf is that ?
<    //CECSocket::OnClose();


I think that the logic is completely different, now in 2.2.3. In version 2.2.3 there is a case
in which even if ConnectSocket(addr) is FALSE (but m_notifier is TRUE) the
routine returns a TRUE. Is this correct? Or maybe it's better I'd stop hangin' around
and go back to my day job?

I'll try to make a test varying RemoteConnect.cpp, anyway.

Cheers,

--
Gaznevada

[wuischke]

Hi,

there have even been more changes in the current developmental version. At least I currently lack the time to research this and I would like to ask you to have a look at the current SVN version and see if the problem persists. Please tell us about the results.

Sorry for not being able to be of more assistance, maybe someone else has a look at it.

Cheers

Edit: If you need an aMuleGUI for Windows, please tell us the version number. We'll provide you with a compiled version. (Least we can do...)

[GonoszTopi]

In version 2.2.3 there is a case
in which even if ConnectSocket(addr) is FALSE (but m_notifier is TRUE) the
routine returns a TRUE. Is this correct?

Yes, it is. If m_notifier is non-NULL it means that the caller is able and willing to accept and process messages. In this case, if the connection cannot be established immediately (ConnectSocket() = false), it may still succeed later (before timing out), in which case a wxEVT_EC_CONNECTION(true) event will be sent to the notifier.