#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

zzz 0) Hi

zzz hi

eyedeekay hi

orignal hi

zlatinb hi

orignal what are we developing now?

eyedeekay for agenda items I have a couple small questions for orignal about UDP tunnels

eyedeekay Once zzz gets back

orignal let's wait

zzz take two

zzz 0) Hi

zzz hi

orignal <orignal> hi

orignal <eyedeekay> hi

orignal <zlatinb> hi

orignal <orignal> what are we developing now?

orignal * zzz вышло (Read error)

orignal <eyedeekay> for agenda items I have a couple small questions for orignal about UDP tunnels

orignal <eyedeekay> Once zzz gets back

orignal * zzz (zzz@nzntmd4wabw2mghv7g2hopxm3htgq5oc2v3tv3zulikzpabvdp2q.b32.i2p) был добавлен

orignal that's all

zzz ha. let's develop a more reliable IRC :)

zzz ok UDP tunnels is 1)

orignal I have a good receipe for you ))

zzz 2) holiday meeting schedule

zzz 3) recipe

orignal about IRC reliability

eyedeekay There are lots of people interested a Discord port, if I had another day in a week

orignal no it's not need to be 3 ))

eyedeekay Not discord, Matrix

zzz 3) discord/matrix/etc

orignal we use UDP tunnels for mumble

zzz ok

orignal and we think to implement SIP tunnel

eyedeekay That was mostly in answer to "More reliable IRC" but we can discuss it

zzz 1) UDP tunnel questions

eyedeekay 2 actually

orignal let's start with 1

orignal what's your question?

eyedeekay 1 is: Do your sessions ever expire or hangup and after inactivity(or when the router shuts down), and if so, what are the rules for that?

orignal let me check

orignal const uint64_t I2P_UDP_SESSION_TIMEOUT = 1000 * 60 * 2;

zzz seems like they have to expire at some point or else it's a memory leak

orignal so expires if 2 mintes if nothing come from that endpoint

eyedeekay Perfect thanks, so then the sender, do they have to resend the repliable datagram at that time?

orignal also

orignal that potrion of the code was witten by psi initially

orignal no

orignal nobody resends datagrams

orignal that's whole idea of UDP/datagrams that they are not reliable

orignal it's app's reponsibility of data intergrite

zzz eyedeekay, you mean after session expiration, the client must send a repliable datagram for the next request, right?

orignal for example on market data feeds there are two identical multicast channels

orignal plus there is retransmission channel

eyedeekay Yes zzz, that's exactly what I mean, I'm trying to figure out how to reopen or replace or whatever needs to happen to a session after a timeout

zzz since the repliable datagram can get lost, and the two sides won't exactly agree on when the session expires, I think the client has to always send repliable datagrams

eyedeekay Could the client send one every 2 minutes or something as a sort of heartbeat?

orignal it's up to client app

eyedeekay Or is there a better solution already in i2pd? Seems like if there were no solution to this then they would be seeing issues with their UDP tunnels

orignal I asked zzz a while ago

orignal unfortunately no such things as ping/pong in datagrams

orignal so you can't do it at I2P tunnels level

orignal a cleint app mist do it

zzz all-repliable requests is the way I would do it anyway, see zzz.i2p/topics/2468 post #11

zzz heartbeats are very expensive in i2p...

zzz and would really limit the server capacity

orignal why are they?

zzz in related news, I checked in my big udp tunnel refactor, took a lot more work than I thought it would

eyedeekay I saw that, thanks zzz, learning from reading it

orignal one hearbeat per minute for example

zzz the usual - bundled LS, 1KB tunnel messages, IBEP/OBGW conn limits

zzz doesn't matter per-client but on the server side if you had a few hundred clients, that's a lot

orignal disagree

orignal if your server sends it to many clients

orignal it can bundle into single 1K message

orignal just different delivery instruction

zzz anything else on 1) ?

eyedeekay I had one more question:

eyedeekay does the sender of the first repliable datagram know that the receiver has has received it and if so, how?

zzz disagree why?

zzz lag, got it

orignal now you know

orignal it's not too much overhead in my opinion

zzz :)

orignal in my implementation no

zzz yeah does it only send one repliable datagram or does it keep sending them until it gets one reply?

orignal racthets message doesn't carry any payload

orignal technical blocks only

orignal however it might be done thour ack request

orignal like we do for LeaseSets

orignal only one ofc

orignal you always send a datagram only once

zzz yup

orignal that's that whole idea of UDP

orignal data goes out without delay

orignal also when you think about UDP mind multicast

zzz I mean if you had multiple requests on the client side all at once, do you send them all repliable until you get one response, or still just send the first one repliable

orignal I rely on what's in current buffer only

orignal first repliable, others are raw

zzz ok

zzz anything else on 1) ?

eyedeekay Nothing else

zzz 2) holiday schedule

zzz I propose we skip 12/27 and 1/3. 12/20 we can have a meeting or not, up to you all

orignal I'm fine wtih 20-th and fine with skipping 27 and 3

zzz and that we come back on 1/10 ready to work on SSU2 again

zzz thoughts?

orignal fine

eyedeekay Fine by me

zzz eyedeekay, zlatinb ?

eyedeekay Works for me

eyedeekay I thought I replied already, maybe more lag...

zzz ok, we'll have a meeting next week and then skip two weeks

orignal нуы

orignal yes

zzz 3) discord/matrix/etc

orignal and IRC

orignal seems you are lagging hard

zzz yeah

orignal then two things

orignal 1. IRC itself

orignal users on reliable internet never disconnect at Ilita

zzz 3a) IRC itself

orignal also no netsplits

orignal however here I got disconnected every day

orignal and you know my recipe )))

zzz all I can say is ask the server ops on #irc2p to investigate

zzz maybe it's java bugs, but it's really hard to figure out

zzz I'm still having problems getting LS sometimes

zzz there's nothing I can do about irc server problems or questions, I know nothing

orignal 95% users of Ilita are i2pd

orignal but Java users also complained about disconnects

orignal even blamed me

orignal that our servers inteniannaly kick them out ))

orignal now 3b

orignal maybe it's time to start using XMPP?

orignal e.g. jabber

orignal we are running our servers and it works fine from everywhere

orignal desktop clients, mobile clients and web clients

zzz 3b) discord/matrix/xmpp

orignal yes

zzz yeah it's not that hard to hook them up to a server tunnel

orignal what do you thing about xmpp?

eyedeekay Write off discord, no chance of that really

zzz we used Mattermost for about 2 years?

orignal 2dpg43zlfophx5jo4xeqc6cx3zm4x3tfdoinbfuzychf5lwn3dhq.b32.i2p

eyedeekay Mattermost is pretty easy all told but it doesn't federate

orignal out XMPP test serever

zzz the thing that scared me about mattermost is it had a lot of anonymity holes, and the operator didn't really care

orignal 2dpg43zlfophx5jo4xeqc6cx3zm4x3tfdoinbfuzychf5lwn3dhq.b32.i2p:2222/index.html

dr|z3d matrix is "interesting" but it's a lot heavier to run than irc on the client side.

orignal web interface

zzz I don't know anything about XMPP

orignal what did you have for internal messanger at your last job?

zzz email

orignal XMPP is open protocol

orignal but more progressive than IRC

zzz yeah I know what XMPP is, but not enough to have an opinion.

orignal you can transfer files or voice/veideo for example

eyedeekay I have a clearer path to a good Matrix homeserver than I do an XMPP server

eyedeekay Pretty sure there's a Matrix plugin for libpurple too, so pidgin/adium

dr|z3d nothing wrong with IRC per se, but I can confirm that for me, at least, i2pd seems a lot more stable on the network than java i2p.

orignal also history

orignal dr|z3d can you please send me a file here )))

orignal now you know what's wrong with IRC

orignal you just can't

dr|z3d so you put it on a webserver. not difficult.

orignal IRC was developed in the days when everybody had own IP

orignal ipv4

zzz we never even got close to closing all the anonymity holes in mattermost, and mikal never even tried

orignal dr|z3d directly

orignal through IRC client

dr|z3d semantics, orignal ;)

orignal not really

orignal some our users use ansdroid

zzz as developers all we can do is encourage people to put up servers and try it, plug the leaks, make it work

orignal they have IRC client but not browser

orignal wirking in I2P

orignal zzz, but seriously

orignal people always ask me

orignal why IRC rather than XMPP

zzz that goes for any application really

orignal XMPP is more modern protocol than IRC

orignal and have more features

dr|z3d instead of thinking "irc can't do direct transfer over i2p" perhaps think more along the lines of "can dcc be patched to use destinations?"

zzz we have dcc support now

dr|z3d I never understood how that worked, I always thought it was ip -> ip?

orignal zzz where?

orignal in IRC tunnel code?

orignal dr|z3d yes, for IRC it must be a direct connection

orignal while XMPP can do it through the server

dr|z3d right, so I'm querying zzz about how it got it working.

dr|z3d if dcc can use destinations instead of ip addresses, then it's a win all round.

orignal in my opinion you must have a server tunnel

orignal for incoming connnections

orignal like Retroshare does

zzz what are you proposing orignal ?

orignal XMPP

zzz nobody needs my permission to use XMPP :)

orignal ofc

orignal but we need to talk to you

orignal reliable way ))

zzz yeah if you enable incoming dcc then we publish the LS, and DCC works

orignal so I do need a server tunnel. Right?

zzz there's a whole bunch of code to handle it, I wrote it maybe 12 years ago, nobody uses it, not enabled by default

dr|z3d wait, so dcc works without compromising ip addresses?

orignal dr|z3d it tries i2p address

orignal not a problem

orignal but second tunnel

orignal while XMPP doesn't need a second tunnel

zzz right

orignal for files exchange, etc.

zzz it's a client tunnel with a published LS. not a second tunnel

dr|z3d well, if dcc works then that's one less issue with irc, orignal.

orignal dr|z3d second issue is disconnects

orignal IRC server doesn't store history

orignal even if you use a bouncer you still lost messages

orignal if you bouncer got disconnected

zzz or maybe it is a second tunnel orignal. I don't remember

dr|z3d disconnects is probably something to look into, possibly some sub-optimal code.

eyedeekay I didn't know that XMPP did that

dr|z3d server history, that's potentially something to talk to ircops about, they're best placed to log everything.

zzz anything else on 3b) ?

eyedeekay Looks to me like a port

eyedeekay Nothing from me

zzz anything else for the meeting?

orignal I had something

dr|z3d a recipe?

dr|z3d potato soup, perhaps? :)

zzz 4) go ahead

orignal yes

orignal my initial question

orignal what are we developing now?

orignal SSU2?

zzz that's the only thing on the list right now that I know of

orignal yes

orignal basciallty I don't develop a new code

zzz not sure what you mean

orignal no projects for new code

orignal that's what I mean

orignal SSU2 is not ready for coding yet

zzz that's right

zzz thanks everybody, see you next week

orignal bye

zzz I was wrong, the DCC client and server tunnels are separate from the normal IRC tunnel