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

orignal R4SAS как думаешь не пора ли ведро перевести на C++20 ?

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

whothefuckami <~orignal> R4SAS как думаешь не пора ли ведро перевести на C++20 ?

whothefuckami Так уже 23 вышел

whothefuckami Алсо, какие фичи c++20 в проекте используются в принципе?

orignal посмотри по коду какие

orignal например atomic<shared_ptr

onon Я тут решил SSU2 поковырять и так и не смог разобраться с ACK-ами. Как получатель отвечает на входящие пакеты? Только если сам что-то отправляет обратно, или если получает флаг SSU2_FLAG_IMMEDIATE_ACK_REQUESTED?

orignal SendQuickAck

onon Однако m_IsDataReceived = true; выставляется и при получении case eSSU2BlkI2NPMessage

orignal вызывается всегда в конце пачки

onon Или я что-то не перепутал

onon А ACK блок в пакет не вставляется?

orignal метод FlushData

orignal нет

orignal можно наверное сделать но я не стал для простоты

orignal хотя наверное вставляется надо уточнить

onon if (!sent) SendQuickAck (); QuickAck он отправляет только если SendQueue () ничего не отправил

orignal отправляется Ack

orignal если есть место

onon Я просто у себя вижу, что иногда ACK-и перестают приходить

onon То есть если места не хватило, то он отправит без ACK блока и SendQuickAck не сделает

orignal строка 492 SSU2Session.cpp

orignal всегда Ack для каждого нового пакета

orignal не так

orignal он воткнет в сущесвующий

orignal else // drop Ack block completely

orignal packet->payloadSize = 0;

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

onon Вот я пытаюсь понять, это они так пачками теряются или клиент просто не отсылает ничего

orignal ну вот видишь логика

orignal всегда когда вызывается Flush

orignal а он вызывается когда кочается поток для данной сессии

onon Вроде в спеках указано, что нужно акки слать регулярно

onon Но не на каждый полученный пакет

orignal так и я не шлю на каждый

orignal а только на серию

onon У меня почему-то аки получаются на 1-3 пакета

onon Серии у тебя считаются как?

onon Когда их буфера всё вычитал?

orignal идут UDP пакеты

orignal несколько штук подряд для одной сессии

orignal потом бац прилетел для другой

orignal тут я вызываю Flush

orignal и если закончились в буфере

onon А если они долго не заканчиваются

onon Такое может быть?

orignal там ограничено число

orignal 64 максимум вроде

orignal SSU2_MAX_NUM_PACKETS_PER_BATCH = 64

onon SSU2_MIN_RTO = 100 вот это неправильно

onon Я понимаю зачем так сделано, но так лучше не делать

onon На малых RTT ретрасмиты становятся бессмысленными

orignal я не помню зачем так

orignal ну давай сделаем 10

onon Не, ничего пока не меняй

onon Там таймаут сессии на это завязан

orignal надо отдельный тред на отправку делать с пейсером как ты говоришь

onon Может стоит в SSU2Session::SendQueue () добавить если мы ACK блок уже отправили то выставить m_IsDataReceived = false, чтобы ещё SendQuickAck () дополнительно не делать

onon А если else // drop Ack block completely то m_IsDataReceived = true

orignal там мы же дальше проверяем

orignal ну смысл есть возвращать отправлен ли уже Ack

orignal bool ackBlockSent = false;

onon D j,otv gjlevfnm yflj

onon В общем подумать надо

orignal bool SendQueue (); // returns true if ack block was sent

orignal ))))

orignal все уже слеано

onon Да, действительно

orignal неудачное называние переменной там просто

Vort "<@onon> Я понимаю зачем так сделано" потому что комп может залагать, на каждое заикание делать перепосылки - слишком много шума

onon Если у тебя реальный RTT=20мс

onon То ждать 100 мс для ретрансмита - это плохо

Vort у меня был реальный RTT 1мс, на локалхосте и постоянно шли глюки из-за того что комп тупил

Vort кстати, по-моему ещё были причины для минимального RTO

Vort надо проверить, что там Java делает. по-моему у них тупо гранулярность таймера 100мс

orignal возможно