udp Определить пропажу пакета

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

Посмотри протоколы типа fast и sbe, и то как их использовали на том же moex, вдохновись так сказать. В кратце - нужно ввести сквозной номер пакета.

казнить нельзя помиловать

при такой постановке задачи, это не решается вообще

он же написал, без доб заголовков

Как ты собираешься проверить целостность данных без избыточности. Можно каждый пакет нумеровать, когда избыточность - это сумма всех счетчков (в заголовке). Можно контрольную сумму считать и передать в конце дополнительно спец пакет с этой контрольной суммой и узнать что сообщение из нескольких пакетов испорчено. Можно коды Хеминга или Рида-Соломона прикрутить и восстанавливать(!) битые пакеты.

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

Я для себя просто не представляю быстрой работу алгоритма когда данные из килобайтных блоков надо выковыривать и склеивать, а не читать огромным сплошным куском (как сделано сейчас), в котором пришедшие блоки лежат последовательно в адрессном пространстве.

На приемной стороне нужно понять что пакеты потерялись или перемешались, не предпринимая мер к повторной отправке (просто отбросить).

Вообще это один-в-один требования к кодированию голоса в IP телефонии, когда перемешивать нельзя для корректного декодирования, а то что потеряно - уже не нужно. Так что гугли про RUDP. Но без хидеров никак.

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

Ты уж определись, нужен тебе дополнительный заголовок или нет. А кто этот заголовок сделает - это уже дело десятое.

В общем, тебе нельзя помочь. Успехов

Вообще это один-в-один требования к кодированию голоса в IP телефонии, когда перемешивать нельзя для корректного декодирования, а то что потеряно - уже не нужно.

Ну всё же не совсем. Обычно есть буфер, там могут копиться перемешанные и восстанавливаться и ожидаться задержанные.

А зачем проверка корректности пакета в голосе?

для сообщений ~10мб время расчета составляет около 400 мс

Как и на чём считаешь?

Без доп заголовков - пусть себе tcp использует или голый ip. Сэкономить 4ре байта это такое себе по сравнению со сменой стека.

Я по-прежнему щетаю, что ТС либо запускает свой код на тостере, либо очень медленно щетает.

На коленке накорябанный на жабке бенчмарк, за который меня будут больно бить, показывает ~3 мс на 10 мегабайтах в неразрывном буфере:

long total = 0;
        
long acc = 0;
        
for (int iteration = 0; iteration < 100; iteration++)
{
    byte[] data = new byte[10_000_000];

    Random rnd = new Random();
    rnd.nextBytes(data);

    long start = System.currentTimeMillis();

    CRC32 crc32 = new CRC32();
    crc32.update(data);
    long value = crc32.getValue();

    long stop = System.currentTimeMillis();

    total += stop - start;

    acc += value; // чтобы упоротые не говорили про оптимизации
}
        
System.out.println(total / 100);
        
System.err.println(acc);

не корректность а порядок пакетов

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

а для понимания, возьмите любой вав файл или пцм

нарежте на одинаковые куски(в ваве ясно дело данные а не с хидером)

перемешайте

и проиграйте

ЛОЛ

анон, как и обычно, флудит тупаком с кучей пустых строк.
pepehands.bmp

Нумерация пакетов же.

чья бы корова мычала лол [quote] Nick: izzholtik ID: 176586

Дата регистрации: 24.03.20 20:18:24 Последнее посещение: 30.07.20 11:06:22 Статус: новый пользователь В игноре:

Oberstserj - пустослов LGH - тупак, грубиян SM5T001 - тор головного мозга Забавные люди:

Black_Shadow - верит всему хорошему про AMD и не верит всему плохому t184256 - у сестры обои на телефоне похожи на его аватарку [/quote]

Crc32 в табличной реализации.

crc32 довольно медленная функция, можно попробовать xxhash32 или xxhash64.

Ну, OpenJDK берёт реализацию crc32 из zlib, а там я вижу вот это вот. Да и какая разница, табличная реализация или «в лоб», если скорость достаточная?

Спасибо. Обязательно попробую

А «система» за тебя это делает конечно же на квантовом сопроцессоре, поэтому все так быстро. Просто передает квантовому стирателю указатель на заголовок пакета, и вот в памяти уже как бы и не заголовок пришел, а сам пакет, какой еще заголовок, не было ничего.

работу алгоритма когда данные из килобайтных блоков надо выковыривать и склеивать

А чо там принципиально сложного? Зарезервировал массив из 10240 1024-байтных блоков. По приходу пакета прочитал номер пакета из первых 2 байтов, используешь его как смещение в массиве и копируешь оставшиеся 1024 байт по этому смещению. В итоге получаешь плоский упорядоченный регион в памяти с данными (это если потерь пакетов не было). Можно пожертвовать плоскостью памяти, если не хочется данные копировать, и сделать битовый массив, взводить в нем бит если пакет пришел, потом идти по этому массиву и по простой формуле вычислять смещение блока