Задача синхронизации по WiFi

для этого есть UDP, смотреть как сделано в SIP софтфонах типа ekiga.

Для таких целей в качестве транспорта обычно используется UDP, а не TCP, плюс на приемном устройстве данные немного буферизируются - используется т.н. jitter-buffer. Кроме того обязательно столкнешься с проблемой разбегания частот - кварц, тактирующий АЦП на передающем устройстве будет разбегаться (ничего идеального нет) с кварцем, тактирующим ЦАП на приемном устройстве, поэтому воспроизводиться будет чуть быстрее/медленнее, чем записываться.

Не понял, почему UDP? Он не гарантирует правильный порядок передачи данных, не гарантирует их целостность. А мне как раз нужен верный порядок и целостность.

>А мне как раз нужен верный порядок и целостность

тогда тебе лучше написать их самому

TCP попросту не даст тебе выкинуть «задержавшийся» пакет, именно из-за требований порядка и целостности.

Я прочел здесь http://ru.wikipedia.org/wiki/VoIP про то, что юзают UDP для повышения скорости передачи. Но мне же нужно как раз *то*, что уже *реализовано* в TCP-протоколе?

Зачем я буду писать велосипед поверх UDP, если есть готовый TCP - я этого не понимаю? Я не такой великий спец, что напишу лучше, чем инженеры TCP.

Только я забыл - UDP *не гарантирует* целостность данных, то есть, пришедшие данные могут быть совершенно другими, чем мне послал отправитель, так?

плюс на приемном устройстве данные немного буферизируются - используется т.н. jitter-buffer

Да, таковой есть. Почитал про динамические джттер-буфера. Но мне нужна как раз минимальная задержка между приемом звуковых данных и их воспроизведением, то есть, буферизовать до усрачки я не могу - я должен как можно быстрее их передать в очередь вопроизведения.

Кроме того обязательно столкнешься с проблемой разбегания частот - кварц, тактирующий АЦП на передающем устройстве будет разбегаться (ничего идеального нет) с кварцем, тактирующим ЦАП на приемном устройстве, поэтому воспроизводиться будет чуть быстрее/медленнее, чем записываться.

ничего идеального нет

ipHone идеален. Шутка.

В моем случае, я полагаю, это можно опустить, но благодарю за информацию, хотя она и очевидна.

Искажение отдельных бит в пакете маловероятно из-за контроля ошибок на нижележащих уровнях модели OSI. Пакет может потеряться или прийти в неверном порядке.

Потому что свойства протокола TCP противоречат твоей задаче — передача данных в реальном времени с минимальной буферизацией. TCP — это один большой буфер неопределенного размера, который гарантирует очередность и целостность потока данных, но никак не гарантирует время доставки «пакетов».

TCP — это один большой буфер неопределенного размера, который гарантирует очередность и целостность потока данных

гарантирует очередность и целостность потока данных

Что такое очередность - ясно. Но что тогда «целостность потока данных» - гарантия того, что данные не искажены? Или здесь идет намек на установление виртуального канала передачи тройным рукопожатием?

Плюсую обертку над UDP.

>Плюсую обертку над UDP.

она даже есть и называется RTP

ortp, mediastreamer ?

> Не понял, почему UDP? Он не гарантирует правильный порядок передачи данных, не гарантирует их целостность.

За правильным порядком фреймов должен следить как раз jitter-buffer. А насчет целостности - если в джиттер-буфер приходит запрос «дай следующий фрейм», а этого фрейма нет, то обычно используется специальная функция кодека (speex, celt или что там у тебя), которая пытается предсказать данные затребованного фрейма Конечно она не может полностью восполнить потерю, но при размере фрейма 10-20 мс ты никаких щелчков или искажений даже не услышишь.
Будешь гнаться за целостностью - налетишь на ситуацию, когда фрейм пора уже воспроизводить, а его нет. В результате воспроизведение придется останавливать до прихода данных.

> В моем случае, я полагаю, это можно опустить, но благодарю за информацию, хотя она и очевидна.

Если не требуется воспроизведение в реальном режиме времени, то можно опустить. В противном случае - счастливой отладки ;-)

> Да, таковой есть. Почитал про динамические джттер-буфера. Но мне нужна как раз минимальная задержка между приемом звуковых данных и их воспроизведением, то есть, буферизовать до усрачки я не могу - я должен как можно быстрее их передать в очередь вопроизведения.

Это типичная проблема для всех VoIP задач. Тут нужен компромисс - при большом размере буфера будет большая задержка, зато более гладкое воспроизведение. При маленьком размере буфера он не всегда сможет компенсировать джиттер, в результате чего появятся щелчки и т.п.
Повторюсь, твоя задача совсем не нова и все известные мне реализации в качестве транспорта используют UDP. Даже при потоковом вещании видео. И как верно заметили выше, RTP - хороший, годный пример.

Понял, большое спасибо.

удалять задержавшиеся пакеты.

как раз нужен верный порядок и целостность.

DivisionByZeroException has been thrown

Сопровождай каждый пакет последовательным номером. Принимаются только пакеты номером больше чем у предыдущего пакета. Вот и весь алгоритм.