IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/07/31
robin I am writing a program that uses SAMv3 to send and receive Datagrams. Is there a way to turn on logging in the Router that will show messages arriving and leaving?
obscuratus robin: I guess this is Java I2P? You can set the logging for SAM to debug, but if that doesn't give you enough info, you'll need to mod the router code.
eyedeekay I think so, I'll find it. If there's not, I'll see what it would take to add it.
obscuratus robin: What Sam library are you using (or are you maybe rolling your own from scratch)?
eyedeekay robin is yours the one where everything is a primary session?
robin On the client side it is my own SAM library, written in Python. That is part of what I am trrying to debug.
robin eyedeekay The datagrams are an ADDed session beneath a Primary session
eyedeekay Thanks that's what I thought
eyedeekay net.i2p.sam.SAMv3Handler=DEBUG should do it for both streaming and datagram sessions
robin And yes, this is the Java router
robin I had the impression form the latest SAM spec that using sub-sessions was the preferred way to go
eyedeekay I wouldn't say preferred, but I do find the approach compelling
eyedeekay It arguably simplifies the mental model for people developing apps
robin My SAM library uses Python async 'context handlers' extensively. It results in very clean code provided one is comfroatble with async programming.
robin *comfortable
eyedeekay It shows
robin Thanks, I will try that DEBUG flag. Symptom is, one program sends a message over its UDP channel but the other instance never sees anything arrive.
robin It is a simple multi-user chat program that does not use a central server like IRC
obscuratus I've been playing with Datagrams on the C library. I think I'm seeing similar. The client-server arrangement I'm playing with is stupid, and it just occasionally hangs for no reason.
eyedeekay Could be something is wrong, let's see what setting the DEBUG flag tells us
robin Both chat instances are connected to the same Router, so that log should capture the entire exchange.
robin After I set the DEBUG flag, do I need to restart the rtr?
obscuratus robin: No.
obscuratus The logging changes are picked up on the fly.
robin Ok, I have logs now from both chat instances, plus the SAM log. I am printing them out and will compare
robin Hmm. Not setting the address string on session initiation is one obvious problem. The two instances can't find each other.
robin They get a TRANSIENT address each time.
robin btw, there is a NullPointerException and an IllegalStateException in that log. I am not sure if it is related - it is from yesterday
eyedeekay You have a gitlab account IIRC?
robin Yes.
robin Tis chat program is not there yet
eyedeekay Feel free to post the log in an issue and I can look into it
robin I saved the log, so I can extract that portion
robin git.idk.i2p/robin unreachable. I will try later
dr|z3d cake.i2p/pastebin if you want somewhere to post logs.
robin Expires in 2 hours
robin Oh, router version 2.3.0-0
Opicaak because "clienttps" is null, typo?
Opicaak Probably not
eyedeekay I don't think that one is related
obscuratus I've been looking over robin's error. We really need for clienttps to exist at that point, or else our Bloom Filter XOR stuff won't work.
obscuratus I've never run across this error before. :/
obscuratus It looks like robin is using I2P+ maybe? I don't think canon has an log message like: FloodfillMonitorJob: Only 1495 ff peers and we want 5000 so we are becoming floodfill
obscuratus Oh wait, I did find that "so we are becoming floodfill" message in canon. So I take it back. :)
eyedeekay I wonder why it isn't there...
eyedeekay Tweaked my logging so I can at least see which client it is
eyedeekay If I see it happen that is
eyedeekay We could also probably safely generate an xor value the same way we do for exploratory if we don't have the clientttps
obscuratus Even in the short bit of log provided, I see other signs that there were gears, cogs, and springs flying out everywhere. I am curious, but I think the failure is upstream of that logging info.
obscuratus If robin can give some guidance on how to replicate, I'll give it a swing when I get a chance.