#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

orignal zzz you asked me about our UDP tunnels protocol desciption.

zzz thanks, will take a look when I have a minute

orignal fine

zzz how does server tell UDPTunnel where the datagram is going?

orignal it remember where it came from ans associate with port

orignal once if get use datagram to this port it sends back to that dest

zzz so UDPTunnel server-side uses a pool of ports and sends/recvs on them and keeps an internal table of far-side-destination -to- port ?

orignal right

orignal identify session by port

zzz good for the doc ))

orignal well this is psi's part ))

zzz on client-side, the far-end dest is a configuration, like a standard tunnel?

orignal e.g. not written by me

orignal yes, you say destination I2P address and that's it

orignal you ofc local port you listen to

zzz and I think you said it in the doc, but even though you're doing retransmissions, you don't buffer and deliver in-order to the client/server, right?

orignal no I don't do any restransimission

orignal send and forget

orignal bascially I only care if the path if alive

orignal also I don't care about ordering

zzz oh ok, seqn/acked is only for diagnostics?

zzz and path check

orignal well it's not

orignal but not implemented yet

orignal onon wanted to delay if we send too fast

zzz can you send "plain ack" with no seqn and no payload?

orignal yes, that's we usually do for unirection traffic like video stream

orignal also forgot to mention in the doc we set number of tags to 800 by default

orignal path check is really the key thing

orignal we switch between paths frequently in streaming

zzz so why do you keep an 'unacked datagrams' list at all?

orignal we don't keep datagram we keep only timestamps

orignal for RTT

orignal second, it's a plan for future imprevements

orignal if this list is too big we should stop reading new datagram from local socket

orignal we limit this window for now

orignal const size_t I2P_UDP_MAX_NUM_UNACKED_DATAGRAMS = 500;

orignal drop after 500 unacked

zzz ok

orignal as I said onon suggests to stop reading socket instead dropping and let OS do it

zzz raw vs. dg3 is a configuration option?

orignal in what sense?

orignal like maximum interval?

orignal because usually it's RTT/10

zzz in your doc you mention raw datagrams? when do you send those instead of datagram3?

orignal in between RTT/10

zzz ohhhhh ok

orignal got datagram is less that RTT/10 send raw otherwise datagram3

zzz you did say that but didn't sink in ))

orignal well let me add

orignal or well also forgot to mention that garlic message is limited like to 1700 or so

orignal same as for streams basically

zzz makes sense

orignal what I have missed if one restarted session buyt it will be fixed

orignal *one side

zzz the client side sounds pretty easy, server side is harder with the port mapping/management stuff

orignal yes, and again I'm not clear with it since its psi's code

zzz you have to timeout your port mapping on the server side after a while

orignal yes

orignal const uint64_t I2P_UDP_SESSION_TIMEOUT = 1000 * 60 * 2;

orignal 2 minutes idle

zzz so this is old psi code and you recently switched to DG3 and made everybody upgrade at once?

orignal it was old psi code

orignal that didn't work well

orignal I made some imprevements for ratchets if I remeber he didn't use raw datagrams etc.

orignal once we had datagram3 with options block we started this seqn/acked stuff

orignal to maintain path

orignal but sessions/ports logic is still psi's

zzz ok and then once you had DG3 then you started wireguard server proxies for various VPNs?

orignal before people was able to run maincraft

orignal well wireguard worked even without DG3 but not good

orignal habr.com/ru/articles/869816

orignal acetone's article from year ago

zzz are you setting i2cp from/to port or leaving them at 0?

orignal in gzip header?

zzz yes

orignal real ports from client

zzz ok

orignal and they are used

orignal see, client tunnel might have muttiple client

orignal we differentiate them by port

zzz doc says 'client tunnel has only one session'

orignal session between destinations

orignal so I have client tunnel to zzz.i2p they can connect to zzz.i2p only

orignal they can't connect to different destination

zzz so on client side you can configure multiple? like send port 9999 to zzz.i2p and port 1111 to minecraft.i2p?

orignal changed doc

orignal no, you have to create multiple tunnels

orignal at least for now

zzz ok

orignal but it's good idea to configure by listen port

orignal just nobody reached this point

orignal well there is even no enrypted LSes for datagrams

orignal due to original psi'd design

orignal need to rewrite many thing to enrypted LS

orignal *supprt

zzz interesting stuff, thanks for writing it up

orignal thank you for commenting

orignal will upload corrected version

orignal psi's implementation had two major problem

orignal 1. it could flood tunnels easily

orignal 2. it couldn't detect if a tunnel is dead and kept sending to noweher

orignal ha ha, onon

orignal he is the man

onon Waht

orignal gostcoin.i2p/UDPTunnel.txt

orignal discussing with zzz how it works

onon interesting

onon > Old unaaked datagrams older than 2*RTT gets removed from unacked datagrams list.

onon rly?

orignal why not?

onon need to recheck

orignal well it's commented out

orignal for some reason

orignal onon кстати я тут проблему увидел в коде

onon Где какую

orignal а что если у нас будет 2 клиента с одного клиенского тоннеля

orignal а на сервере будет 2 сессии с свовими seqn

orignal чинить надо

onon А в чёмпроблема

onon Ну будет и будет

orignal потому что номера у нас между дестинейшинами

onon А где что сломается

orignal вторая проблема

onon Клиент будет отвечать невпопад?

onon Номерами разными?

orignal если одна сторона рестартует

orignal в попад наверное

orignal но все равно это надо переделать

onon Смотри только не сломай ничего

orignal а вот при рестарте одной стороны надо завести флаг sequence reset

onon Зачем

orignal ну поломаю потом починим

onon Совместимость нужно чтоб была

orignal рестратовал у тебя идет с нуля

onon Потому что уже в проде

orignal а та сторона будет акк слать на номер со старой сесии

orignal допустим у него там 1000

orignal а ты снова начала с нуля

onon Сессию закрывать просто нужно

onon С двух сторон

onon И начинать новую

orignal а как закрывать?

orignal все равно придется флаг слать

onon Нужно это было продумывать до релиза

onon На уровне сессии это сделать можно?

orignal ничего страшного