@StormyCloud
@eyedeekay
@not_bob_afk
@orignal
@postman
@zzz
%Liorar
%acetone
%cumlord
%mareki2p
%snex
+BeepyBee
+Onn4l7h
+Onn4|7h
+profetikla
+qend-irc2p
+r00tobo
+uop23ip
+xHarr
Arch
BubbRubb
Dann
H20
Irc2PGuest32716
Irc2PGuest50537
Irc2PGuest63942
Irc2PGuest74254
Irc2PGuest92133
Irc2PGuest95708
Meow
Over1
RN
T3s|4_
ac9f_
anontor
dollarthief
dr|z3d
floatyfloatilla
halloy13412
makoto
maylay
n1
nZDoYBkF_
nilbog
ntty
poriori_
r00tobo[2]
shiver_
simprelay
solidx66
thetia
u5657
vivid_reader56
weather_uncommon
zer0bitz_
orignal
any updates about timestamp threshold?
dr|z3d
none to speak of.
dr|z3d
(assuming you're asking if zzz got back to us yet)
dr|z3d
flux.2 just landed. multi-modal.ai.cloudflare.com
orignal
well manybe I was disconnected
dr|z3d
man-yebbies!
dr|z3d
harry: define a manyebby.
dr|z3d
harry: define a manyebby.
H20
A manyebby is a term for a person who believes the moon's phases dictate their emotional state, yet still insists their ex is “just gone.” A poetic tragedy in three acts.
zzz
the question is about expiration checking of TunnelDataMessages at middle hops?
dr|z3d
I think so, though there may be other places where resetting the expiry may make sense.
zzz
I don't see anything special about middle hops, and there's no "inner" timestamp, so it should be just our standard check
dr|z3d
I'd have to remind myself what I was looking at, but iirc, we're resetting the expiry and forwarding it on. orignal's sending with the original expiry intact, which results in lots of stale packets being forwarded and then dropped.
zzz
thats not what I'm seeing so I'll need a pointer
dr|z3d
zzz: TunnelParticipant.java is where I was looking. had to consult on-disk channel logs.
dr|z3d
method: private void send(HopConfig config, TunnelDataMessage msg, RouterInfo ri) {...}
dr|z3d
also, you asked yesterday about gradlew version, now on: Gradle 9.2.1
zzz
ok so where we're resetting the expiration to now + 10s ?
dr|z3d
private void send(HopConfig config, TunnelDataMessage msg, RouterInfo ri) {
dr|z3d
if (_context.tunnelDispatcher().shouldDropParticipatingMessage(TunnelDispatcher.Location.PARTICIPANT,
dr|z3d
TunnelDataMessage.MESSAGE_TYPE, 1024))
dr|z3d
return;
dr|z3d
//_config.incrementSentMessages();
dr|z3d
long oldId = msg.getUniqueId();
dr|z3d
long newId = _context.random().nextLong(I2NPMessage.MAX_ID_VALUE);
dr|z3d
_context.messageHistory().wrap("TunnelDataMessage", oldId, "TunnelDataMessage", newId);
dr|z3d
msg.setUniqueId(newId);
dr|z3d
msg.setMessageExpiration(_context.clock().now() + 10*1000);
dr|z3d
msg.setTunnelId(config.getSendTunnel());
dr|z3d
OutNetMessage m = new OutNetMessage(_context, msg, msg.getMessageExpiration(), PRIORITY, ri);
dr|z3d
if (_log.shouldLog(Log.DEBUG))
dr|z3d
_log.debug("Forward on from " + _config + ": " + msg);
dr|z3d
_context.outNetMessagePool().add(m);
dr|z3d
}
zzz
yup
dr|z3d
yeah, there.
zzz
looks like it dates back to 2005 jrandom
zzz
not sure why
zzz
why aren't we using the incoming expiration as the outgoing expiration?
dr|z3d
I don't think it's necessarily a bad thing, maybe better than receiving an very soon-to-be-expired message and forwarding it as is, which is what i2pd does.
dr|z3d
maybe to mask the number of hops?
zzz
perhaps
zzz
but in any case this expiration is only until you get to the gateway and it gets defratmented
zzz
where are you seeing 'lots of stale packets get dropped'
zzz
?
dr|z3d
I was seeing a ton of messages with > 60s expiry being forwarded, which I assumed was i2pd.
dr|z3d
or rather, with > -60s expiry.
dr|z3d
maybe not a ton, but enough to ask myself, wtf is going on here?
zzz
but at what point in the stack are you seeing those?
dr|z3d
this is all I can give you right now: Dropping stale TunnelDataMessage [2919828558] ➜ Expired 28063ms ago (Cutoff: 15s)
dr|z3d
that was from 11 days ago. I think I've upped the cutoff to 1m since then.
zzz
but where in the code is that
dr|z3d
same method.
dr|z3d
I have:
dr|z3d
// Drop if expired more than 60s ago
dr|z3d
if (originalExpiration < now - 60_000) {
dr|z3d
if (shouldLogWarn) {
dr|z3d
long age = now - originalExpiration;
dr|z3d
_log.warn("Dropping stale" + msg + " -> Expired " + age + "ms ago (Cutoff: 60s)");
dr|z3d
}
dr|z3d
return;
dr|z3d
}
zzz
I don't have that so that's your doing, and we already have centralized expiration checking so I don't know why you'd add another just for TUnnelData
zzz
and not sure why the whole question was about me tweaking code I don't have?
dr|z3d
the question was about expiry or extension of those messages, not my tweaks, and the divergence between i2p and i2pd.
zzz
ok
zzz
if it takes a minute for a msg to get down a tunnel thats pretty bad anyway
dr|z3d
sure, it ain't special.
dr|z3d
but it i2pd is getting a message just within that window, and then sending it on with the same expiry, that's even less special.
zzz
as far as whodunnit, could just be soembody's clock skew, or something else, not sure you can point the finger at i2pd
dr|z3d
that's why I figured a 15s cutoff seemed about right. even that's pretty generous, but the suggestion was that we should all standardize the behavior.
dr|z3d
more likely i2pd than java, since we reset the expiry in java-land. i2pd doesn't, hence my suspicion messages were coming from i2pd.
zzz
as I said I don't think we need checking in TunnelParticpant specifically for TunnelDataMessages, we have centralized validation in InNetMessagePool -> MessageValidator
zzz
why did you add it?
dr|z3d
better visibility into what was going on, probably.
zzz
jrandom's 10 sec seems a little tight, maybe 20 would be better
dr|z3d
20s extension?
zzz
yeah, now + 20
dr|z3d
and what about a cutoff? presumably messageValidator() handles that?
dr|z3d
if (now - (Router.CLOCK_FUDGE_FACTOR * 3 / 2) >= expiration) { ...
dr|z3d
so your cutoff is 90s? seems way too generous, assuming your fudge is 60s.
zzz
thats the jrandom validator, -90s to +240s
zzz
with the 60s fudge our checks are usually 2 * fudge to allow for one router skewed each direction
dr|z3d
ok
zzz
so it doesn't seem terrible
dr|z3d
20s latitude on expiry and a 20s extension feels right, but maybe that's too tight on the latitude.
dr|z3d
like you said, if a message is a minute old, it's already a bit wrong.
zzz
well message validator was 90 and you put in code to be 15 instead for tunnel data messages and cant remember why. I'm not inclined to reduce the 90 any
dr|z3d
that was initially. it's 60s right now.
zzz
right but the reason we got here is you put in a check 6x tighter than canon then wondered why you were tossing so many tunnel messages?
dr|z3d
no, not really *chuckle* I was more interested why I was seeing messages expired over a minute prior being received. and wanted to blame orignal. :)
dr|z3d
orignal: get a haircut.
orignal
so, what's the actual value?
orignal
60 or 15?
orignal
e.g. current_time > expiration_time + 60 or +15?
zzz
my code is -90 < exp - now < +240. drz recently changed from -15 to -60
orignal
so my code is even less +/- 60
orignal
between current and expiration
orignal
what do you do at tunnel participant?
zzz
+60 sounds too low on the high side, since skew could be 120 by itself, then add the actual expiration
zzz
I have one check for everything. drz added this 15 (now 60) check for tunnel hops only, I don't have that
orignal
huh? don't we have expire time itself?
orignal
I set expirztion time as current time + 8 secs
zzz
sure but the guy that set the expire time may be skewed from the guy that checks it
orignal
right, that's why I have 60
orignal
assuming max allowed clock skew is 30 secs
zzz
our max skew is +/- 60 so paired max skew is 120, plus if I set an expieration 60s later, that's 180
orignal
then what is drozd complaining about?
zzz
not sure
dr|z3d
I wasn't complaining so much as wanting a) some clarification and b) perhaps some coordination so we all do more or less the same thing.
orignal
in my opinion we should reduced allowed clock skew
dr|z3d
that's generally what I was thinking. zzz thinks we should be more permissive.
orignal
it's not 2003 now
orignal
almost every device have time sync
dr|z3d
well, I think 30s latitude with a 15s extension for tunnel data messages (any others?) sounds about right.
dr|z3d
if we receive a message that's within our window, we reset the expiry and send it onwards.
zzz
dunno about 2003 but we've had built-in SNTP since 2004 and there's still plenty of clock-skewed routers in the network to deal with