It sometimes gets into a loop where it sends msg to
itself asking itself to "pass this along", then
receives the message, then wraps it in another layer of
encryption and sends it to itself again.
I don't want to disable relay server behind relay -- I want to fix the
"prevent looping relay" code. I agree about v0.6.2 -- it was my mistake
that I put it in v0.6.3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a few ways why you might want to do that, but they aren't
common. For example, maybe node A can talk to relay server B but
can't talk to relay server C. Maybe node D can talk to relay server C but
can't talk to relay server B. Then D could send to A via B via C.
Part of my motivation for doing it the "loop prevention" way instead of
the "don't use a relay behind relay" way is that I've already implemented
the loop prevention, and since it doesn't work that means there's a bug in
what I wrote. :-)
But another reason is that your node can't control what other nodes do.
Suppose your node tells me "If you want to talk to me, send to relay
server B.". I try to send to relay server B, and I find out that "If you
want to talk to relay server B, send to relay server C.".
Well, in my opinion, my node should go ahead and send to relay server
C. It can't hurt (as long as B and C do proper loop-prevention). Maybe
B's internet connection has fluctuated, and he is normally directly
reachable, but for the next five minutes he isn't directly reachable so we
use relay server C for the next five minutes.
What do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i think that both cases must not happen.
in the first scenario i do not understand how it should occur
like that, after a contact info lookup at a MT both A and D
should reach B and C. if that takes too long to wait for, we
have to fix that slowness (i am afraid we really have to)
instead allow chains of relayed relayed relay servers.
and the second case simply would not happen if we did not
allow relay relay servers. (Again except for a short period, but
again, we must shorten those periods anyway).
Imagine 30 curious behind relay broker users switch on the RS
in their broker.conf. We might end with 30-part relaying
chains, having messages travelling for days...
... i mean, the network seems slow enough already, and RSs
will become pretty busy with data relaying anyway. Why
multiplying their traffic?
I think we have to make sure we have enough directly
reachable RSs, and we should disable RSs announcing itself as
soon as the are behind relay.
A loop prevention won't hurt, though... but it should be active
in real emergency cases only...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm getting massive mem usage -- on the order of 1 GB.
Maybe this is related to the relay server loop. I'll raise
the priority, and I'll also think about actually taking time
to look at it myself. Here's some data:
2004-10-09_14:54:09 (Broker) This Broker's ID is: <5pqjf>
(full name: 5pqjfw7futpjhr59qgyguojjntpudpnc) or in
mojosixbit encoding: 21yS06WcWp4Tf3GAacEpFFsxtEw
2004-10-09_15:27:39 (Conversation) MTM: msgId: <eypnm> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <5mmp7> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <jgp3j> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <iwanf> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <1a974> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <7megi> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <imduk> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <q5js8> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <rt3nw> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <8kyq5> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <sf93u> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <caaoj> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <rgr4h> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <dz69w> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <dgy5z> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <5ur9s> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <kfio8> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <ywdop> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=642335
Yeah, we need to disable relay server as soon as it find itself
behind relay.
I guess that one is worth being put into 0.6.2 group.
Logged In: YES
user_id=52562
I don't want to disable relay server behind relay -- I want to fix the
"prevent looping relay" code. I agree about v0.6.2 -- it was my mistake
that I put it in v0.6.3.
Logged In: YES
user_id=642335
hm, i do not understand... who is helped by a relay server
behind a relay? why should one want to enable that?
Logged In: YES
user_id=52562
Well, that's a good question.
There are a few ways why you might want to do that, but they aren't
common. For example, maybe node A can talk to relay server B but
can't talk to relay server C. Maybe node D can talk to relay server C but
can't talk to relay server B. Then D could send to A via B via C.
Part of my motivation for doing it the "loop prevention" way instead of
the "don't use a relay behind relay" way is that I've already implemented
the loop prevention, and since it doesn't work that means there's a bug in
what I wrote. :-)
But another reason is that your node can't control what other nodes do.
Suppose your node tells me "If you want to talk to me, send to relay
server B.". I try to send to relay server B, and I find out that "If you
want to talk to relay server B, send to relay server C.".
Well, in my opinion, my node should go ahead and send to relay server
C. It can't hurt (as long as B and C do proper loop-prevention). Maybe
B's internet connection has fluctuated, and he is normally directly
reachable, but for the next five minutes he isn't directly reachable so we
use relay server C for the next five minutes.
What do you think?
Logged In: YES
user_id=642335
i think that both cases must not happen.
in the first scenario i do not understand how it should occur
like that, after a contact info lookup at a MT both A and D
should reach B and C. if that takes too long to wait for, we
have to fix that slowness (i am afraid we really have to)
instead allow chains of relayed relayed relay servers.
and the second case simply would not happen if we did not
allow relay relay servers. (Again except for a short period, but
again, we must shorten those periods anyway).
Imagine 30 curious behind relay broker users switch on the RS
in their broker.conf. We might end with 30-part relaying
chains, having messages travelling for days...
... i mean, the network seems slow enough already, and RSs
will become pretty busy with data relaying anyway. Why
multiplying their traffic?
I think we have to make sure we have enough directly
reachable RSs, and we should disable RSs announcing itself as
soon as the are behind relay.
A loop prevention won't hurt, though... but it should be active
in real emergency cases only...
Logged In: YES
user_id=52562
I'm getting massive mem usage -- on the order of 1 GB.
Maybe this is related to the relay server loop. I'll raise
the priority, and I'll also think about actually taking time
to look at it myself. Here's some data:
2004-10-09_14:54:07 () Crypto++ version: 5.0
2004-10-09_14:54:07 () Berkeley DB version: (4, 1, 25)
2004-10-09_14:54:07 () PyBSDDB version: 4.1.6
2004-10-09_14:54:09 (Broker) This Broker's ID is: <5pqjf>
(full name: 5pqjfw7futpjhr59qgyguojjntpudpnc) or in
mojosixbit encoding: 21yS06WcWp4Tf3GAacEpFFsxtEw
2004-10-09_15:27:39 (Conversation) MTM: msgId: <eypnm> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <5mmp7> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <jgp3j> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <iwanf> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <1a974> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <7megi> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <imduk> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <q5js8> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <rt3nw> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <8kyq5> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <sf93u> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <caaoj> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <rgr4h> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <dz69w> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <dgy5z> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <5ur9s> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <kfio8> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'
2004-10-09_15:27:39 (Conversation) MTM: msgId: <ywdop> ::
'pass this along' with <5pqjf>, failed, failure_reason:
'timeout'