#saltr (irc2p) | I2P+ 2.7.0-10+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

dr|z3d some optimizations in console sidebar and snark javascript, please give it the usual throbbing if you're running the latest (soon-to-be-uploaded) + dev build and report any issues.

dr|z3d also in the upcoming dev build, realtime filtering on /tunnelpeercount .. to filter by bandwidth tier only, use tier{L|M|N|O|P|X} in the filter input.

dr|z3d filter is persistent.

dr|z3d dark theme only for now, other themes to follow.

zzz hk, I'm still standing by on that swarm with logging enabled, no sign of your client yet

hk zzz: if you still want to do it, which I deeply appreciate I really do I want to communicate that, you'd have to use a separate trackers because pstman's tracker uses destination enfrocement

hk I have a working build that primarily works with i2p/i2p+. with i2pd it uses MASTER session and fails

hk for whatever reason

zzz the reason is that i2pd doesn't support sam 3.2/3.3

hk postman's*

hk thats why, that makes sense

hk hold on im just trying to get this to copyt paste for you gimme a sec

hk wc4sciqgkceddn6twerzkfod6p2npm733p7z3zwsjfzhc4yulita.b32.i2p/a

hk you'll have to use this tracker zzz then we can proceed

zzz not sure if that's true about postman, but you said you're connecting to other peers, so you did it somehow

hk did I? not without trackers?

hk I may have mentioned PEX, that would require my dependency, go-i2p-bt to support it. If it's dht, that hasnt been implemented

zzz thought you said you were talking to peers

hk talking to peers in the sense that I am able to talk to peers through a tracker,m that was my misunderstanding I apologize

hk there is no dht or pex at this time

zzz just use opentracker.dg2.i2p that everybody announces to

hk ok no problem ill have to program for that

zzz right but you don't 'talk through trackers', you get references to other peers from the tracker, then talk to them directly

hk ah okay okay

zzz so you don't have peer-to-peer connections working yet?

zzz opentracker does do dest enforcement

zzz so you're not announcing on the same session as your p2p session?

zzz but you said you're downloading from peers so you must have p2p working

hk zzz: the extent of peer communcation is being able to get a list of peers from a tracker, the handshake process, data transfer (leech only for now),

hk yes yes to an extent

hk hmm

zzz so then why can't you connect to me?

hk I believe it was due to you using postman's tracker, and me using a separate tracker

hk thats is what I believed

zzz but the other peers aren't using your special tracker, are they?

hk but like you said, that shouldnt have to be true

hk there are a limited amount of peers using this tracker, yes it's not as popular as postman's but I wasnt able to get postman's to work because I would get an html error saying the request was invalid so I had assumed it was destination enfrcement

hk and this tracker in partifular doesn't do it, that being said

hk I have not tested opentracker.dg2.i2p, i'll hard code that

hk hm that's curious

hk I was using sam subsessions to connect to the tracker

hk separately

hk from the global session, that shouldnt happen

hk that could be why

zzz yeah don't do that, announce on the same session you use for p2p

zzz wc4s is running zzzot so it presumably has dest enforcement also, not sure why it would work but postman wouldnt

zzz but it's not listed in the Antenna torrent file so no peers should be announcing to it

hk do you see an ET/EepTorrent client right now? just curious, im downloading right now

zzz the only way I'd 'see' it is if you connected to me

zzz which you arent

zzz I'm seeding so I'm not going to connect to you

hk understood yeah, ill hack to get back to work on this gimme another few hours or so and let me get dg2 hardcoded

hk right

zzz work out why postman is failing because my understanding is that zzzot does dest enforcement and postman may not? yet your results are backward from that so I'm confused

zzz you could also run your own zzzot if that helps your testing

hk got it thanks

zzz you also said you saw my peer yesterday, that was either from postman or dg2 or you didn't really, it wasn't from wc4s

hk right I assumed as such haha

hk zzz: dg2 is ready

hk I got it to work with the same url encoding that I did with wc4s. but postman still fails

zzz are you using two different subsessions for announce and p2p, or two different master sessions?

hk same global stream, different keys

hk two different subsessions that would mean

zzz huh? all subsessions have the same destination (same keys)

hk hmm

zzz so that's fine, dest enforcement is not the problem

orignal yes, i2pd doesn't support 3.3 completely

hk orignal: aww I see

orignal hiwever datagrams from 3.2 work in 3.1

zzz look at if you're doing compact annuonces or not, that may be it

hk orignal: so is dht will not be able to work with bittorrent with i2pd?

hk zzz: im doing non-compact

zzz right, you can't do udp and streaming on same session in 3.1

orignal let me explain

zzz try switching to compact

orignal why i2pd doesn't support newer SAM

zzz here we go

hk uploaded=0, downloaded=0, cleft=65546; I dont know why it still works with this url encode but it does with opentracker

hk ok ok

orignal zzz, in i2pd's sam 3.1 you can

orignal it supports databgrams

hk hm

zzz not on same session

hk left=65536*

orignal so i2pd doesn't support new SAM because no client to test with

hk hm

orignal and it supports datagrams because polistern needed it for pboted

hk pboted?

orignal so, give me a client app and I will implement

zzz then maybe hk's will be the client you need to test, someday

orignal I'm waiting for SAM 3.3 cient for many years

hk I see, so there is a feature that you require to test against and it's not there so they're incompatible?

zzz bittorrent+udp+dht+sam is not easy, nobody's done it yet, you have a long way to go to get there

hk damn

orignal well I tried to implement SAM 3.3 but didn't test

hk ahh I see

hk zzz: unreal, I got postman's tracker to work he has a check internally to see if "left" matches the actual lnegth of the torrent

hk and I set compact to 1

zzz not sure if that's true, compact may have been the trick

hk yeah probably compact

zzz if you can handle compact responses, you should switch to that; if not, then implement it

hk zzz: it's all good now

hk I even got it to combine multiple peers from multiple trackers

hk so whenever you're ready, im ready to test

zzz Unknown (LUVU) 0.0.0 CtDl

hk thats me

hk 0.0.0 sounds right

hk it should show up as ET or EepTorrent but alas

zzz so -ET is the final ID? I'll hardcode you in

hk nono hold on I

zzz it's 'EepTorrent' exactly?

hk I dont know how the client broadcast works exactly, let me do extensive testing

hk I want to be sure it's correct before we hardcode

hk sorry

zzz dunno what 'client broadcast' is, but all I need to know is that the final peer ID starts with -ET, which is what it is now

hk sorry I mean "broadcasting" a term I sorta just spin up now, like telling other bittorrent clients what your client is

hk yeah it should just be ET

hk ah screw it yeah you can hardcode ET to stand for EepTorrent

hk zzz: thanks so much :D

zzz 11/20 08:50:49.328 DEBUG [ LUVU@CtDlid] org.klomp.snark.PeerState : LUVU@CtDlid 3370 rcv request(68, 65536, 16384)

zzz 11/20 08:50:49.328 INFO [ LUVU@CtDlid] org.klomp.snark.PeerState : Request received, but choking LUVU@CtDlid 3370

zzz and then you dropped and reconnected

hk drop and reconnects are quite often

hk not "quite often" but

hk common

hk you cant download a torrent in this without it retrying eventually

hk retrying connections*

hk zzz: what percent does your client tell my client is at?

hk actual is 68%

hk but biglyBT is saying 2%

zzz 64.97%

hk ah so yours is correct

hk well, roughly

zzz now 71.18

hk correct correct

hk ah good good

zzz [Connection vMsU4w/8h2Bsw from dkm5o5qrvsvtheogjvv3tquhbzut2bebmv6i7ban62lzvmlq7l4q.b32.i2p up 28s wsize: 78 cwin: 78 rtt: 1379 rto: 3183 unacked out: 2 unacked in: 1 sent: 968 rcvd: 39 ackThru 965 ssThresh 64 minRTT 692 maxWin 128 MTU 1812]

zzz 78 is damn good

hk woah

hk well this is running on a router in a remote vps that is set to max speeds

zzz I don't think you're handling choking right, I choked you and you dropped again

hk damn I see

hk download complete

hk it still tries handshakes even after the download is complete hahah

hk there are also i/o timeouts

hk for some reason

hk zzz: thank you for helping me test

zzz np, maybe others can help out also

zzz ET hardcode checked in

hk glad to hear :D

zzz you can do the same thing, run snark on the same swarm, I can give you hints on good classes to log if you need it

hk please do

zzz org.klomp.snark.Peer=DEBUG

zzz org.klomp.snark.PeerState=DEBUG

zzz and grep for LUVU which is the internal ID for eeptorrent

hk nice nice got it

zzz the term for 'telling other clients your name' is 'extension protocol', see BEP 10

zzz handshake.put("v", "I2PSnark");

hk yup yup

dr|z3d ok, latest + dev build now supports various filter types and query parameters.

dr|z3d e.g. /tunnelpeercount?filter=L&type=tier

dr|z3d or tier=L in the input. input and addressbar url should be synced.

dr|z3d please test if you're running dev builds and report any issues. thanks!

dr|z3d other types = host|hostname, ip, hash, cc|country

dr|z3d to filter by type in the input, cc=fr etc.

T3s|4 dr|z3d: i'm likin' /netdbmap?class=tierX; quite vivid and explanatory :)

dr|z3d thanks for the feedback, T3s|4.. I think it's another useful visualization that may help when the network's under attack, or just generally to see where the fast peers (or floodfills) are at.

dr|z3d map updates more frequently now, every 15s. was 30.

dr|z3d and obviously you noticed the static info box instead of the follow-the-cursor tooltip which I wasn't a fan of.