eyedeekay
Hi everyone welcome to the dev meeting
eyedeekay
1. Hi
eyedeekay
2. Release Date
orignal
hi
orignal
3. SAM 3.3 protocol descripancy
RN
:)
eyedeekay
Any other topics for this meeting? Please keep it essential
eyedeekay
Thanks orignal
orignal
4. what the next meeting with zzz?
orignal
*when
obscuratus
hi
orignal
hi
eyedeekay
4. Not a topic because it can't be answered without him in attendance, ask him on your own time
eyedeekay
Consider 3 on the agenda though
orignal
4. we should schedule the next meeting with him when he is ready
eyedeekay
sure. When he is ready
eyedeekay
Let's get started
eyedeekay
2. Release date
orignal
release is 18-th. right?
eyedeekay
We're going on the 18th, that's 2 weeks from now
orignal
yes, fine for us
eyedeekay
Ok that's settled
eyedeekay
3. SAMv3.3 protocol discrepancy
orignal
3.
orignal
we have two version of SAM 3.3
orignal
and both of them are 3.3
orignal
maybe we should use different names like 3.3.1 or 3.3.BLM?
orignal
brb in 5 minutes
RN
3.3.og
eyedeekay
If this is about the primary/master thing added the note to the SAMv3.3 specification you asked for
orignal
yes, but the problem is
orignal
that both implementation return 3.3 in response
orignal
we should add some attribute to differentiate them
orignal
that's my point for the meeting
eyedeekay
Sure that's not a bad idea all told
eyedeekay
It could be also be useful for SAM to be able to return the implementation/version of the host router for that matter so libraries could respond to it
dr|z3d
not sure that's necessary.
dr|z3d
we just document the fact that the client should check for PRIMARY and if no response, try MASTER. job done.
orignal
yes, so what do you think? should we introduce version like x.y.z ?
eyedeekay
From a lib developer standpoint it would be pretty handy
orignal
dr|z3d I diasgree because we have two SAM 3.3 with the same name
eyedeekay
Let me think about it and write a proper change to the spec
dr|z3d
orignal: then the plan should be to harmonize the implementations so they're feature equivalent.
orignal
the idea is
orignal
if we have two different protocols they must have different names
dr|z3d
sure, if whatever this new protocol is, isn't following the official spec, then don't call it SAM at all.
eyedeekay
I mean, regardless of the primary/master thing i2pd sometimes lags a little bit on SAMv3 features, I stand by my 'from a lib developer's standpoint' statement
dr|z3d
is that what we're quibbling over? PRIMARY/MASTER, or are there more significant differences?
orignal
it's not about SAM 3.3 it should be in general
orignal
I propose to add "revision"
orignal
like 3.3 = 3.3.0 and then 3.3.1, 3.3.2 etc.
eyedeekay
dr|zed Datagram support was one for a while, not sure anymore
eyedeekay
There are a few more on the spec page
dr|z3d
so the i2pd implementation is lagging, or it's completely diverged from the protocol? the way orignal tells it, they've invented something entirely new.
orignal
i2pd implementation of 3.3 is not complete ))
orignal
being honest
eyedeekay
More like just a little incomplete
eyedeekay
That's why I suggested implementation/version
dr|z3d
if that's the case, then i2pd should downgrade its version until it is. I don't see what revisions brings to the party.
dr|z3d
if you're incomplete, then claiming you support 3.3 shouldn't be happning. 3.29 perhaps.
orignal
that's fine
orignal
up to you guys
orignal
I can call 3.3.wlm if you wish ))
dr|z3d
keep the trolling in #saltr, this is serious business time :)
eyedeekay
I'll give it the serious parts of the proposal some thought
eyedeekay
Anything else for the meeting?
dr|z3d
yeah, one more thing.
dr|z3d
router spoofing.. how you getting on with that provisional proposal orignal?
orignal
dr|z3d I would like to discuss it with zzz
orignal
and it's not router spoofing, it's address spoofing
dr|z3d
you know how zzz operates, he really does like a proposal to look at so he comes prepared to the ensuing discussion.
orignal
I would like to discuss the issue with him first
orignal
since he was the one who designaed SSU2
obscuratus
So, probably nothing on this before the release. I guess we can talk amongst ourselves on the Java-I2P side, but do we need to implement something before the release on this?
dr|z3d
no time, too late in the cycle to start.
dr|z3d
big changes deadline has passed.
eyedeekay
Yeah let's wait until next time
dr|z3d
and by the time we've all had this discussion, it'll be post release.
obscuratus
OK.
eyedeekay
Thanks everybody for coming, next meeting in 2 weeks?
dr|z3d
baff it, eyedeekay. we're done here. :)
dr|z3d
2 weeks should be good, maybe zzz will be with us by then.
eyedeekay
ok thanks everybody for coming
dr|z3d
while both of you are here, eyedeekay, obscuratus, can either of you confirm we've got a client leaseset display dupe issue?
eyedeekay
I'll set the topic in a few minutes
dr|z3d
I'm currently addressed that with css, but that's just a short term fix so I don't go nuts trying to identify where the issue is.
obscuratus
The 18th will be release day. Busy day for the next meeting.
obscuratus
Doesn't the LS display show all LS for all clients? If so, that may be where the dups are coming in.
dr|z3d
it's a dupe that occurs multiple times, including the summary table. so no. it's definitely a bug.
obscuratus
dr|z3d: So, if you have three clients, you get three sections, one for each client, but every LS listed under each?
obscuratus
So they're all repeated.
eyedeekay
Which checkin are you merging? I fixed this a couple days ago
dr|z3d
I've fixed the nav menu so it behaves more or less as it did pre-segmentation. Way too busy otherwise.
eyedeekay
obscuratus I'd rather wait 3 weeks that's why I asked
eyedeekay
3 weeks better or 2? Show of hands lol
obscuratus
eyedeekay: 3 weeks would be fine for me.
eyedeekay
dr|zed orignal, 2, 3, don't care?
dr|z3d
I merged the huge bundle of commits.
obscuratus
eyedeekay: Re: dr|z3d's issue, I think I'm still seeing what he is describing. I think I'm current, but I was just about to update with the last four commits.
orignal
what?
orignal
next meeting?
dr|z3d
3 weeks sounds about right.
dr|z3d
if 2 weeks coincides with release.
orignal
3 weeks is fine
eyedeekay
Yes orignal
eyedeekay
The 3's have it then, next meeting will be the 25th
eyedeekay
It was IIRC the first checkin after the big merge
dr|z3d
thanks
eyedeekay
d3ad082a82f4cbc60c4e350bc038d461f7ef42af
obscuratus
OK, I don't have this in yet.
dr|z3d
can I just globally search and replace floodfillNetDb() with mainNetDb() ?
dr|z3d
nevermind, I see there's a couple of other strings that need replacing.
dr|z3d
eyedeekay: looks like you missed one in FNDF -> protected void createHandlers() {
dr|z3d
// Only initialize the handlers for the flooodfill netDb.
dr|z3d
if (super._dbid.equals("floodfill")) {
eyedeekay
Oh thanks good catch I'll fix it in a minute
dr|z3d
another couple of possibles, not sure if you squashed 'em:
dr|z3d
router/java/src/net/i2p/router/networkdb/kademlia/FloodfillNetworkDatabaseSegmentor.java: _subDBs.put("floodfill", subdb);
dr|z3d
router/java/src/net/i2p/router/networkdb/kademlia/FloodfillVerifyStoreJob.java: ds = getContext().netDb().lookupLocally(_key, "floodfill");
dr|z3d
not 100% sure about the second one there.
dr|z3d
or indeed the first, looking at the code.
dr|z3d
we also have this code in the ff segmentor which looks like it should probably be removed, or at least not forgetten about :)
dr|z3d
// DELETE THIS FUNCTION WHEN YOU'RE DONE!
dr|z3d
private void alsoStoreFloodfill(Hash key, LeaseSet leaseSet) {
dr|z3d
FloodfillNetworkDatabaseFacade fndb = _context.mainNetDb();
dr|z3d
if (_log.shouldLog(Log.DEBUG)) {
dr|z3d
// change these comments depending on whether you store or not. For testing
dr|z3d
// purposes.
dr|z3d
_log.debug("don't store " + key.toBase32() + " to floodfill");
dr|z3d
// _log.debug("also store " + key.toBase32() + " to floodfill");
dr|z3d
}
dr|z3d
// fndb.store(key, leaseSet);
dr|z3d
}
dr|z3d
is that safe to comment out?
eyedeekay
Yes it is
eyedeekay
It's still there but the reason it needed to be deleted is not, now all it does is log a message
not_bob
I don't need anything, just checking in.
dr|z3d
ok, thanks, eyedeekay
dr|z3d
obviously the call above needs commenting out too.
dr|z3d
not sure you squashed this one, eyedeekay, in RouterContext: public FloodfillNetworkDatabaseFacade mainNetDb() { return _netDb.mainNetDB(); }