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

onon В реальной сети там от кучи факторов зависит.

orignal ну нам то надо выбрать значение для реальной

onon Так это верхний лимит просто

onon Надо или этот буфер больше делать или чаще слать чтобы скорость больше была

orignal так верхний лимит знаешь ли паять отжирает

onon Ну вот, тогда думайте

onon Что нужнее скорость или малое потребление памяти

onon Я бы всё-таки думал как сделать напрямую с сокета тогда

onon Чтоб лишнюю память не есть

orignal тогда оставлю как есть

weko [21:50:32] <onon> И тогда общий RTT от сервиса до клиента через i2p будет минимальный

weko Я всё это уже говорил...

weko [22:50:55] <orignal> 2.5 мегабайта хватит ))

weko 640 килобайт хватит всем

weko [22:10:20] <onon> Я бы всё-таки думал как сделать напрямую с сокета тогда

weko Так и надо сделать. Я тот же вопрос задавал, зачем нужен наш буфет, когда можно использовать буфер ос

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

Vort они могут получать данные не из сокета что ли?

Vort то есть, вопрос по сути в том, что сломается если убрать одну из прослоек с буферизацией

Vort или ничего не сломается, а дело лишь в "красоте" кода (в правильности уровней абстракции)

orignal например адресная книга

orignal или скажем с другого дестинешина

onon А нельзя гибрид какой-то сделать? Если есть сокет - то берём из него, если нет - то по нынешней схеме...

orignal можно но надо много делать

onon Вот тебе задание тогда

onon Чтоб свободное время с пользой проводил

Vort принцип работы сокета довольно универсален. вполне может быть, что по такому же принципу можно и остальные источники данных привязать

Vort то есть, чтобы сигнатуры вызовов были сокетно-совместимы (примерно), а дальше уже виртуальными методами выбирать конкретную реализацию

Vort но может я фигню говорю, не знаю

orignal ну надо что то передавать с методом ReadSome

orignal onon я переделал чтобы больше 64K не забирал

onon А зачем?

orignal ну чтобы делало то что заявлено

onon Ну ладно

orignal если мы говорим что масимум там 64K то и должно быть 64K а не что попало

onon Ну значит правильно сделал

onon Что там за проблемы в NTCP2?

orignal майор начинает слать побайтно на порт пока не обнаружит на каком байте отваливается

orignal так он распознает NTCP2

orignal эту тему еще лан поднимал давно

onon Я думал нет вообще проблемы "увидеть" NTCP2

onon Оказывается вот как

orignal я вроде это делал но проверю

Vort при публично доступной netdb странно придумывать хитрозакрученные методы обнаружения

orignal для этого надо самому быть частью сети

orignal а так простой скрипт отпрелеляет

Vort так это надо неопределённое количество адресов и портов перебрать

Vort проще частью сети стать )

orignal нее

orignal майор видит соединение на какой то IP/порт

orignal пытается стукнуть скриптом и понять что там на той стороне

onon А когда релиз?

orignal через месяц

orignal сделал

orignal то что дед говорил

weko [13:32:44] <Vort> принцип работы сокета довольно универсален. вполне может быть, что по такому же принципу можно и остальные источники данных привязать

weko Да. Ту же адресную книгу можно сделать через сокеты ос, ну то есть соединится с собой же

orignal не надо ее делать через сокеты

orignal надо через интерфейс с методом Read

Vort weko: видел такое много раз в другом софте. но считаю это грязным методом

weko Ну да, здесь нормально сделать можно

weko У нас есть какой то стрим, и к нему либо цепляем объект с сокетом, либо цепляем объект с буфером

weko Для туннелей первый вариант, для остального второй

weko Ну прокси ещё, да

weko Но суть та же

weko В идеале, адресная книга, вместе с проксёй, должна быть отдельно, но на практике это излишнее усложнение без достаточного профита