@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
Danny
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest48042
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cancername
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
not_bob_afk
plap
poriori_
profetikla
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
RN
here is me, walnuts and hydraulic presses
RN
hehehe
dr|z3d
and stilettos. don't forget those :)
RN
only on days that end in "y"
dr|z3d
:)
RN
who let a monkey into the code!
dr|z3d
you might need to screenshot that for context, well, in this channel :)
RN
yeah, there's a chimp in a hoodie blended into the interface of the i2p+ web console
RN
just one of doubtless many more easter eggs when you look around that i2p+ has to offer
robin
eyedeekay Router gets an exception if I close the primary session TCP socket. Will sending a "QUIT" request first avoid this? Spec says QUIT is optional
eyedeekay
Quit is usually optional but it might not be in your case, I seem to recall us running into an issue when the SAM API is on a separate host in the past
robin
It does not seem to be fatal, but I am trying to eliminate anything 'unusual'
robin
Clinet is no sending a UDP message to the router's UDP port, but no mention of that appears in the log. Do datagrams get logged there?
robin
is NOW sending
eyedeekay
Yeah they should be logged, but I haven't looked too much into the specifics of the logging yet
robin
ok.
robin
Wireshark soes the message leaving the client mahcine with no error coming back. I have not tried running WS on the router yet
robin
I will do that tomorrow
eyedeekay
OK
eyedeekay
I have an appointment in the morning but I'll be back at noon, my bouncer will be here to get the scrollback
eyedeekay
Well noon my time, I guess that's what like 5UTC?
robin
ok
eyedeekay
Everybody knows my time zone anyway
robin
eyedeekay wireshark on my I2P router node shoes my UDP datagram (938 bytes long) arriving to port 7655. But no mention is made in the router's log with net.i2p.sam.SAMv3Handler=DEBUG
robin
And netstat shows that port 7655 is open, udp6, by java
robin
Interesting, the newer 'ss' program shows it open as [::ffff:(my router IP)]:7655
robin
It occurs to me that the router will silently drop any UDP message it receives that it thinks is not in the correct format.
obscuratus
robin: It might be worth your while to play around alittle with some of the other SAM libs that support UDP, and see if you can figure out what they're doing differently.
obscuratus
I've been using UDP Datagrams connections on the libsam3 C library a lot lately on my testing network, to simulate traffic.
obscuratus
I'm not trying to convince you to switch to C, but it might help you sort out the differences.
obscuratus
I'm pretty sure polistern's pboted is also using UDP. It's on the C++ i2psam library.
robin
Part of this project is to develop my own library that handles SAM. The chat program is just the application I use to test it.
robin
libsam3. I could look at how they do it.
robin
Yes, libsam3 formats its messages the same way I do.
robin
"3.0 SESSIONID DESTINATION\ndata"
robin
eyedeekay It seems that sending an explicit QUIT *does* avoid the Exception on readline in the router.
eyedeekay
Thanks for the update
eyedeekay
I'm just going over the logging in the SAMv3 app
robin
Still not seing my messages logged though. I am not sure if there is even code to do that - the SAM code is a bit obscure
eyedeekay
You might be ahead to build the branch from source when it's pushed
eyedeekay
Yeah I'm working on some of that this afternoon
robin
One though is that I think SAM will drop a message in the wrong format. But I am sending a message exactly as documented.
robin
I can put one in pastebin.
eyedeekay
Thanks
robin
(If I could figure out how to make pastebin work)
robin
I think this is it paste.idk.i2p/PostmortemPig/edit
robin
It is a UTF-8 encoded byte string
obscuratus
eyedeekay: I've ran into a few early issues/concerns with the nested-netdb changes. Let me know when you've got a minute.
eyedeekay
Now's fine if you've got time
obscuratus
Oops, sorry, you got back just as I switched away and was waiting for a fresh message. :)
obscuratus
Sorry for the crappy etiquette on my part, let me know if you're still around eyedeekay.
eyedeekay
I'm still here and I always see the scrollback :)
obscuratus
I've got two things, one quite a bit bigger. Let me start with the smaller one I actually have a suggested fix for.
obscuratus
On my testing network, I'm the subDb's don't look like they're keeping themselves updated for their RI.
obscuratus
One problem I noticed is that the subDb's are using the floodfill peerSelector, and this causes them to drop the RI.
obscuratus
When I look here at the createPeerSelector, I'm confused...
obscuratus
git.idk.i2p/idk/i2p.i2p/-/blob/i2p.i2p.2.2.1-nested-netdb/router/java/src/net/i2p/router/networkdb/kademlia/FloodfillNetworkDatabaseSegmentor.java#L130
obscuratus
It looks like you're iterating through the subdbs, but returning the on the first iteration, which will almost always be the floodbill subdb, since it's created first.
eyedeekay
Oops yup you're absolutely right, that's a problem
obscuratus
My suggested fix is over in StoreJob.java.
obscuratus
But, like most problems, there's lots of ways to fix this.
obscuratus
I guess you could skip the iterator, and just return this.createPeerSelector() in FloodfillNetworkDatabaseSegmentor.
obscuratus
The bigger issues stems from my observation that the RI in the subDbs aren't getting updated. I have the same RI I start with, and never add new ones or update the ones I started with.
obscuratus
This is bad in itself, but I should be seeing more errors from this behavior (unless the errors are there, but my logging isn't set right).
obscuratus
How can a client be doing the things it needs to do if it never gets the RI for the OBEP and IBGW of its tunnels?
eyedeekay
Logical explanation is that it's still getting those peers from the floodfill context
obscuratus
Presumably, it's going to send DBSM for it's lease set down it's tunnel, and ask for a reply on the IBGW. But it either doesn't know it's inbound gateway, or it's crossing the segmentation barrier.
obscuratus
Do we want it to get RI from the local floodfill context?
eyedeekay
I *think* that it's OK, but I don't know for sure
obscuratus
At any rate, I was wondering what the current desired behavior is here. Maybe I just misunderstand what I'm expecting it to do here.
obscuratus
I'll try to confirm how it's building its Database Store Messages. Maybe that'll give me insight.
eyedeekay
My intention was to target similarity with the i2pd implementation at first, and unless I'm wrong they're getting the RI's out of the big pool
obscuratus
OK, that'll raise another issue with how Database Search Reply Messages are handled. I've got a suggestion on that, so expect something from me on that topic.
eyedeekay
Awesome, keep looking, I need all the help I can get on this
eyedeekay
Thanks very much
obscuratus
Have you had a chance to run the current nested-netdb code much yet? I'm wondering if you're seeing the same thing where the subdb just sits there and never grows or shrinks.
obscuratus
This is specific for RI. LeaseSets seem to work better.
eyedeekay
Yeah that's exactly what I'm seeing too
obscuratus
If we're going to target i2pd's imlementation, maybe we don't need RI at all in the segmented db.
eyedeekay
TBH an ulterior motive of this was to help see if we ever had an RI down a client tunnel unsolicited
eyedeekay
In theory, if we saw that then the RI count would grow
eyedeekay
I think you're right
obscuratus
How solidly do we know if an RI received down a tunnel was solicited or not. I've been trying to find the matching code, but I'm not sure what I expect is there.
eyedeekay
The long and short of it is that I don't think it happens, if they were coming down client tunnels at all they would be getting tagged with the dbid
obscuratus
At any rate, thanks for the clarifications. I have a better idea what's expected now, and have a better idea of what is unexpected.
eyedeekay
Thanks for keeping an eye on it
obscuratus
I *think* I am seeing those, but for some reason they're getting ploinked. Unintentionally I think.
obscuratus
But I need to update the logging messages, added the context for the subDb that the loggin message is associated with.
eyedeekay
Could be the very difficult-to-follow old netDb defenses doing it
obscuratus
Otherwise, I'm never sure if I'm seeing a message for the floodfill subDb or the client subDb
eyedeekay
Good point, I'll make some changes to the logging to fix that
obscuratus
So the good news is, when I run a client (I'm using a simple SAM client for testing), the nested-netdb stuff does seem to be working.
obscuratus
So it must be correctly sending and receiving LS, or it wouldn't work at all.
eyedeekay
Yeah I'm running the current i2p.i2p.2.4.0-test1 branch right now and everything seems to be mostly fine minus one or two wrinkles
obscuratus
Let me re-phrase that.... It must be sending and receiving LS. Need to make sure it's doing it correctly. :)
eyedeekay
Yup. I think it's getting close though