https://github.com/blahness/nes_test

Тестовое приложение для эмулятора nes

В readme ссылка есть на сам эмулятор

Всё на D

Я вообще хз о чем ты рассуждаешь ) В моем ПР есть фикс баги, вполне полноценный. Два чувака уже подтвердили что это хороший фикс. О каких клиентах и серверах ты говоришь я не понимаю.

Он говорит вот о чем. В вайбде есть функция read, которой даешь размер который тебе НУЖНО прочитать, и она блокирует таск пока все эти байты не будут прочитаны или возникнет ошибка. Но так как ты не знаешь сколько тебе нужно читать, то нужно заключить соглашение с тем кто отправляет тебе данные. Например сначала отправляется short с длиной пакета, а потом уже сам пакет. ты сначала читаешь с помощью read этот short (2 байта), а затем при помощи того же read сам пакет длина которого тебе уже известна

Да нету у меня никаких пакетов, есть только TCP поток

Мне надо между двумя tcp соединениями в обе стороны передавать все данные, и делать это быстро

Минус только в том, что нужно заключать соглашение с отправителем, что не всегда возможно. Например чтение данных из стороннего источника

Да нету у меня никаких пакетов, есть только TCP поток

Да, если ето просто стриминг медиаданных, то длина тоже заранее не известна

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

Я должен сразу отослать буфер который мне пришел

Чтобы никого не задерживать.

Я должен сразу отослать буфер который мне пришел

я просто разъяснил, что он имел в виду

лучше разъясни ему что я имею в виду )

Часто бывает, когда пакет можно нормально распарсить только в том случае если он скачался целиком

в этом случае вполне логично слать длину и ждать пока пакет целиком не загрузится

Ну в начале у меня идет socks5 аутентификация, там в первом байте приходит длина пакета, яв се это парсю, это вообще не проблема.

лучше разъясни ему что я имею в виду )

ну у тебя просто стриминг данных или какая-нибудь прокся?

Прокся

а ну да, сокс

И перед стриммингом сначала идет процесс аутентификации, а потом просто два сокета тупо как труба один в другой

тогда я бы тоже делал без длин откуда соксу их знать

В общем мне все нравится, только я нашел скрытопроблему - примерно через час работы прокся начинает отжирать 100% проца и намертво зависает. Как это расследовать я не представляю.

Видимо там в вайбе какой-то шарик за ролик забегает

Видимо там в вайбе какой-то шарик за ролик забегает

да, у меня точно также иногда ложится веб-сервак

Блин хреново

100% цпу и никакие запросы не обрабатываются

рестарт помогает

А у тебя vibe-core или стабильный vibe.d ?

Драйвера пробовал менять?

у меня 0.7.x последний

либевент

драйвера не меняю, потому что это бывает относительно редко

Ладно буду выслеживать, может как-то gdb подрубиться или я хз

я все равно все накуй на эликсир/эрланг переписываю,

у меня подобная херь кстати когда-то на руби была, sinatra зависала похожим образом

может это что-то на уровне ОС происходит, хз

Надо идти в чат к реверсерам и спрашивать

а у тебя виснет только с одним паралелльным соединением?

Один поток, но соединений много

При активном бровзинге прокся где-то 3-4 соединения в секунду может открыть, с паузами

А потом на минуту замолчать и использовать их.

пул соединений?

Не, это уже как там вайб делает, мне все равно

В мой код приходит TCPConnection и я начинаю с ней работать.

а драйвер какой?

event-core?

Да, все стандартное

там reactor кажется

Или proactor?...

стандарнтый eventcore вроде

reactor.proactor - это просто названия шаблонов

Ну в честь них и драйвера называют )

попробуй на libevent или даже libasync

libevent попробую, а libasync вроде пока не поддерживается

Ну в честь них и драйвера называют )

не в вайбе

либевент выпилен

https://code.dlang.org/packages/eventcore

eventcore - это просто эвент луп

только какие-то стандартные нативные драйвера поддерживаются

другой вариант откатиться на 0.7.x

ERROR: S client not available

чисто пробы ради

Часто бывает, когда пакет можно нормально распарсить только в том случае если он скачался целиком

имхо - читать нужно всегда сколько можно прочесть, просто что-бы экономить сисколлы. А потом уже ковыряться в том сколько байт было в заголовке и скоько их еще нужно дочитать. Другое дело кто именно реализует эту “буферизацию” - может и библиотека, а может и пользовательский код. Но говорить - ты можешь прочесть один байт - это как-то очень мелко.

А еще подлее - это говорить что ты можешь прочитать 4096 раз по одному байту :D

да, недостойно высокого звания

имхо - читать нужно всегда сколько можно прочесть, просто что-бы экономить сисколлы. А потом уже ковыряться в том сколько байт было в заголовке и скоько их еще нужно дочитать. Другое дело кто именно реализует эту “буферизацию” - может и библиотека, а может и пользовательский код. Но говорить - ты можешь прочесть один байт - это как-то очень мелко.

экономить сисколлы тоже мелко. будет у тебя скажем в два раза больше сисколов вряд ли это будет узким местом

В опенсорс софте все места узкие )

Не бывает широких мест, бывают не достаточно извращенные пользователи.

экономить сисколлы тоже мелко. будет у тебя скажем в два раза больше сисколов вряд ли это будет узким местом

Это уже как повезет. Вон прокси кроме сисколлов ничего не делает практически. Заранее неизвестно какое приложение будет использовать либу

Если смотреть видос 4к на ютюбе, то оно все же ест 5-6% ядра, что заметно

Я вот думаю, если из TCPConnection не копировать в свой буфер, а писать по ссылке из временного буфера TCPConnection, то должно быть еще эффективнее

в целом согласен, когда я пилил сервер для сетевой игры, я тоже тащил по маасимуму во внутренний буфер и потом уже бил на игровые пакеты.

Ведь в буфер TCPConnection в юзерспейс опять копируется буфер из ядра сетевого стека..

Представляете в каком неэффективном бессмысленном мире мы живем?? Мириады бесполезных копирований, чтения по 1 байту в цикле...

Да, есть такая тема, кажется zero copy tcp

Это уже как повезет. Вон прокси кроме сисколлов ничего не делает практически. Заранее неизвестно какое приложение будет использовать либу

сисколлы они разные бывают. мы тут только сискол запрашивающий данные из буфера сокета рассматриваем, он ничего практически не жрет.

Я вот думаю, если из TCPConnection не копировать в свой буфер, а писать по ссылке из временного буфера TCPConnection, то должно быть еще эффективнее

А зачем копировать в юзерспейсе вообще? Прочел в immutable буфер и работаешь с ним

А зачем копировать в юзерспейсе вообще? Прочел в immutable буфер и работаешь с ним

скопировал в иммутабл буфер?

сисколлы они разные бывают. мы тут только сискол запрашивающий данные из буфера сокета рассматриваем, он ничего практически не жрет.

Не уверен, но может быть

я не уверен, что это вообще сисколл

А зачем копировать в юзерспейсе вообще? Прочел в immutable буфер и работаешь с ним

Ну это становится все более низкоуровнево и более хрупко, если увлечься

я не уверен, что это вообще сисколл

Из socket? Конечно.

Ну это становится все более низкоуровнево и более хрупко, если увлечься

Конечно это дело библиотеки, она должна давать инструмент

Вообще если покопаться в вайбе то там конечно не идеально

При парсинге запроса парсер туда сюда скачет, разбивает строки, копирует во временные параметры кучу раз

То есть это не уровень си/си++

Из socket? Конечно.

ты уверен, что буфер сокета лежит не в юзер спейсе?

То есть это не уровень си/си++

а язык тут причем?

а язык тут причем?

Ну вот на си никогда ни за что не будут копировать что-то куда-то просто так) Займутся байтодрочерством

Ну вот на си никогда ни за что не будут копировать что-то куда-то просто так) Займутся байтодрочерством

ага, а потом heartbleed находим

Ну да, это неидеально

не стоит оно того вообще

ты уверен, что буфер сокета лежит не в юзер спейсе?

На 99.9%