Программирование[11]

Drakonian написал 13 часов назад:

this, у нас большинство людей говорит что вы ебанулись, у нас последние 7 лет такая ситуация, схуяли все орать начали именно сейчас? Типа риск присутствовал все эти 7 лет, но западные СМИ это игнорили, а щас взорвались как по указке. Нам же самим от этого не выгодно... 

Чел, там у штатов чуть дефолт не ебанул, страна потихоньку шла к гражданке. А ты сам понимаешь как они исторически с этим справлялись: срали на соседов по шарику.

GoldRobot написал 6 минут назад:

Drakonian написал 13 часов назад:

this, у нас большинство людей говорит что вы ебанулись, у нас последние 7 лет такая ситуация, схуяли все орать начали именно сейчас? Типа риск присутствовал все эти 7 лет, но западные СМИ это игнорили, а щас взорвались как по указке. Нам же самим от этого не выгодно... 

Чел, там у штатов чуть дефолт не ебанул, страна потихоньку шла к гражданке. А ты сам понимаешь как они исторически с этим справлялись: срали на соседов по шарику.

АРРРРЯЯЯЯЯ ГОСДОЛГ СЫШЫА ВИДИЛИ БЛМ ПЕДИКИ ГЕЙБРАКИ ЦРУ ВСЕ ПОДСТРОИЛО

интересно, каково сейчас МИДу российскому

просто все говорят только о грядущем нападении на украину, и походу ближайшие лет 5 так будет

чисто на полшишечьки уже зацти в харькив сказать привет алохечленсу и обратно уйти, чтоб пластинка сменилась

Rilay написал 10 минут назад:

Kant написал 13 минут назад:

в следующий раз придет например 3 заголовка

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

а что ты читаешь 2 сообщения и выключаешь свою программу?

ну 2 придет заголовка, а тело 2 не поместится, разница то какая

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

Давайте без ебаной политики и так хватает аутистов из полит топанов

Drakonian написал Только что:

Давайте без ебаной политики и так хватает аутистов из полит топанов

Если ты не идешь к полит аутистам, то полит аутисты идут к тебе.

Kant написал 16 минут назад:

Rilay написал 29 минут назад:

Kant написал 31 минуту назад:

в следующий раз придет например 3 заголовка

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

а что ты читаешь 2 сообщения и выключаешь свою программу?

ну 2 придет заголовка, а тело 2 не поместится, разница то какая

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

а как мне сделать так, что если тело не полностью пришло, ждать

добавить слип типа на несколько секунд если байтов недостаточно прочел, чтобы после слипа еще попробовать дочитать?

Rilay написал Только что:

Kant написал 18 минут назад:

Rilay написал 30 минут назад:

Kant написал 33 минуты назад:

в следующий раз придет например 3 заголовка

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

а что ты читаешь 2 сообщения и выключаешь свою программу?

ну 2 придет заголовка, а тело 2 не поместится, разница то какая

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

а как мне сделать так, что если тело не полностью пришло, ждать

добавить слип типа на несколько секунд если байтов недостаточно прочел, чтобы после слипа еще попробовать дочитать?

ты про маршрутизацию в курсе вообще? у тебя пакеты могут пойти разными путями вплоть до того, что один пойдет через всю планету, и придёт к тебе условно через секунду-две, а следующий за ним придёт к тебе за четверть секунды, опередив первый

и tcp тебе гарантирует, что отдаст тебе пакеты в том порядке, как они ушли, а если не дождётся какого-то, пошлёт сигнал источнику типо я не дождался, отправь пож еще раз 

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

madvlaydin написал Только что:

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

что то типа такого?

делаем большой буфер с ожидаемой длиной
делаем маленький буфер
      цикл начинаем (
            читаем маленький
            
            прибавляем маленький к большому

            пока не заполним большой

        )

Rilay написал 8 минут назад:

madvlaydin написал 11 минут назад:

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

что то типа такого?

 

делаем большой буфер с ожидаемой длиной
делаем маленький буфер
      цикл начинаем (
            читаем маленький
            
            прибавляем маленький к большому

            пока не заполним большой

        )

хз, я не знаю правильно ли так делать или нет
 

кант правильно у тебя спрашивает, как у тебя твой код вообще планируется к выполнению? кроном раз в секунду запускать и чекать, пришёл ли пакет от датчика? или просто висеть на сокете и срать в базу данных тем, что пришло?

madvlaydin написал 1 минуту назад:

Rilay написал 11 минут назад:

madvlaydin написал 15 минут назад:

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

что то типа такого?

 

делаем большой буфер с ожидаемой длиной
делаем маленький буфер
      цикл начинаем (
            читаем маленький
            
            прибавляем маленький к большому

            пока не заполним большой

        )

хз, я не знаю правильно ли так делать или нет
 

кант правильно у тебя спрашивает, как у тебя твой код вообще планируется к выполнению? кроном раз в секунду запускать и чекать, пришёл ли пакет от датчика? или просто висеть на сокете и срать в базу данных тем, что пришло?

Ну там у них некая свд есть которая этим занимается, я так сказать подробностей не знаю

Но вроде смысл такой 

Отправляем два запроса трекеру, один запрос на координаты, другой на датчики

Ждём 15 секунд, читаем сокет че он там прислал (два пакета)

Парсим, отправляем дальше 

repeat

Rilay написал Только что:

madvlaydin написал 3 минуты назад:

Rilay написал 13 минут назад:

madvlaydin написал 17 минут назад:

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

что то типа такого?

 

делаем большой буфер с ожидаемой длиной
делаем маленький буфер
      цикл начинаем (
            читаем маленький
            
            прибавляем маленький к большому

            пока не заполним большой

        )

хз, я не знаю правильно ли так делать или нет
 

кант правильно у тебя спрашивает, как у тебя твой код вообще планируется к выполнению? кроном раз в секунду запускать и чекать, пришёл ли пакет от датчика? или просто висеть на сокете и срать в базу данных тем, что пришло?

Ну там у них некая свд есть которая этим занимается, я так сказать подробностей не знаю

Но вроде смысл такой 

Отправляем два запроса трекеру, один запрос на координаты, другой на датчики

Ждём 15 секунд, читаем сокет че он там прислал (два пакета)

Парсим, отправляем дальше 

repeat

ну так и делай буфер на эти 15 секунд, пытаясь вычитать свои 2 пакета, и ассерт сверху, типо за 15 секунд не пришёл полный ответ

madvlaydin написал 1 минуту назад:

Rilay написал 3 минуты назад:

madvlaydin написал 6 минут назад:

Rilay написал 16 минут назад:

madvlaydin написал 19 минут назад:

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

что то типа такого?

 

делаем большой буфер с ожидаемой длиной
делаем маленький буфер
      цикл начинаем (
            читаем маленький
            
            прибавляем маленький к большому

            пока не заполним большой

        )

хз, я не знаю правильно ли так делать или нет
 

кант правильно у тебя спрашивает, как у тебя твой код вообще планируется к выполнению? кроном раз в секунду запускать и чекать, пришёл ли пакет от датчика? или просто висеть на сокете и срать в базу данных тем, что пришло?

Ну там у них некая свд есть которая этим занимается, я так сказать подробностей не знаю

Но вроде смысл такой 

Отправляем два запроса трекеру, один запрос на координаты, другой на датчики

Ждём 15 секунд, читаем сокет че он там прислал (два пакета)

Парсим, отправляем дальше 

repeat

ну так и делай буфер на эти 15 секунд, пытаясь вычитать свои 2 пакета, и ассерт сверху, типо за 15 секунд не пришёл полный ответ

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

madvlaydin написал 24 минуты назад:

и tcp тебе гарантирует, что отдаст тебе пакеты в том порядке, как они ушли, а если не дождётся какого-то, пошлёт сигнал источнику типо я не дождался, отправь пож еще раз 

разве на его уровне уже ТСП не вернет уже собанное сообщение и ему об этом думать не нужно? единственное что может быть (и это кстати справедливо почти для всех систем и сетевых взаимодействий) это приход сообщений приложения в неправильном порядке

Just.Doit написал 2 минуты назад:

madvlaydin написал 28 минут назад:

и tcp тебе гарантирует, что отдаст тебе пакеты в том порядке, как они ушли, а если не дождётся какого-то, пошлёт сигнал источнику типо я не дождался, отправь пож еще раз 

разве на его уровне уже ТСП не вернет уже собанное сообщение и ему об этом думать не нужно? единственное что может быть (и это кстати справедливо почти для всех систем и сетевых взаимодействий) это приход сообщений приложения в неправильном порядке

я если честно не особо секу чё у рилая происходит, еще в прошлом топике потерял нить

я думаю надо либо подписаться на события сокета (ну типо ждем пока tcp раздуплится и соберёт все пакеты и отдаст нам)

либо по кд его дёргать типо а сейчас есть чё? а сейчас? а сейчас? а сейчас? 

ну и естественно обернуть это всё в некий токен, который протухнет за 15 секунд или сколько там в конфижке там

Just.Doit написал 53 минуты назад:

madvlaydin написал 1 час назад:

и tcp тебе гарантирует, что отдаст тебе пакеты в том порядке, как они ушли, а если не дождётся какого-то, пошлёт сигнал источнику типо я не дождался, отправь пож еще раз 

разве на его уровне уже ТСП не вернет уже собанное сообщение и ему об этом думать не нужно? единственное что может быть (и это кстати справедливо почти для всех систем и сетевых взаимодействий) это приход сообщений приложения в неправильном порядке

тсп ничего не знает о сообщениях в его протоколе, он знает только про байты

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

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

апи всегда может вернуть МЕНЬШЕ, чем ты просил, больше не возвращает, тк остаток хранится у ос в буфере и следующий вызов, если было больше, будет уже условно синхронным без ожидания

но тебе как потребителю апи чтения из сокета поебать на это

Just.Doit написал 1 час назад:

разве на его уровне уже ТСП не вернет уже собанное сообщение и ему об этом думать не нужно? единственное что может быть (и это кстати справедливо почти для всех систем и сетевых взаимодействий) это приход сообщений приложения в неправильном порядке

тцп гарантирует соблюдение порядка отправки-доставки

Kant написал 8 минут назад:

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

 

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

апи всегда может вернуть МЕНЬШЕ

Эм, ну не совсем. Зависит от твоей библиотеки сети, и апи ОС. Второе я не знаю, потому прост вот как в либах делают посмотрите нормальных

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/async_read.html

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/async_read_until.html

возможно в го тоже нормально сделано

Rilay said 1 hour ago:

madvlaydin said 1 hour ago:

Rilay said 1 hour ago:

madvlaydin said 1 hour ago:

по сути, тебе надо буфер реализовать, как ты это будешь делать - хз

что то типа такого?

 

делаем большой буфер с ожидаемой длиной
делаем маленький буфер
      цикл начинаем (
            читаем маленький
            
            прибавляем маленький к большому

            пока не заполним большой

        )

хз, я не знаю правильно ли так делать или нет
 

кант правильно у тебя спрашивает, как у тебя твой код вообще планируется к выполнению? кроном раз в секунду запускать и чекать, пришёл ли пакет от датчика? или просто висеть на сокете и срать в базу данных тем, что пришло?

Ну там у них некая свд есть которая этим занимается, я так сказать подробностей не знаю

Но вроде смысл такой 

Отправляем два запроса трекеру, один запрос на координаты, другой на датчики

Ждём 15 секунд, читаем сокет че он там прислал (два пакета)

Парсим, отправляем дальше 

repeat

магазин какой на свд? 10 или 20 патронов?

GoldRobot написал 4 часа назад:

Just.Doit написал 5 часов назад:

разве на его уровне уже ТСП не вернет уже собанное сообщение и ему об этом думать не нужно? единственное что может быть (и это кстати справедливо почти для всех систем и сетевых взаимодействий) это приход сообщений приложения в неправильном порядке

тцп гарантирует соблюдение порядка отправки-доставки

Kant написал 4 часа назад:

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

 

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

апи всегда может вернуть МЕНЬШЕ

Эм, ну не совсем. Зависит от твоей библиотеки сети, и апи ОС. Второе я не знаю, потому прост вот как в либах делают посмотрите нормальных

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/async_read.html

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/async_read_until.html

 

возможно в го тоже нормально сделано

ну так всё именно так и написано

buffers

One or more buffers into which the data will be read. The sum of the buffer sizes indicates the maximum number of bytes to read from the stream.

handler

std::size_t bytes_transferred // Number of bytes copied into the // buffers. If an error occurred, // this will be the number of // bytes successfully transferred // prior to the error.

ты даешь сокету буфер, он заполняет его как может

сколько заполнил - в коллбеке

может быть меньше, не может быть больше

эта логика везде и во всех языках одинаковая

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

Kant написал 9 минут назад:

может быть меньше, не может быть больше

 

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/async_read/overload2.html

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/CompletionCondition.html

https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/transfer_all.html

boost::asio::async_read(socket_, boost::asio::mutable_buffer(recv_buffer_.data(), recv_buffer_.size()), boost::asio::transfer_all(), cb);

Пока не заполнится весь буфер либо не произойдет ошибка, твой кб не позовется.

ииииии?

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

каким образом оно отменяет предыдущее?

я не ферштейн, что ты пытаешься показать