2013-11-09 4 views
0

Я реализовал чат в Java с UDP. У меня есть один поток, который отправляет данные списка массивов другому клиенту и один поток, получающий данные от другого клиента. Список массивов может быть заполнен методом.UDP Packet loss Fix

Чтобы отправить сообщение, из списка массивов выбирается байт [], его длина отправляется, а затем байты отправляются.

Теперь я думаю о потере пакетов. Как я могу реализовать исправление для этого? Отправка сообщения назад была бы очень неэффективной. Я могу отправить сообщение обратно, если получатель не получил сообщение, потому что я знаю длину сообщения, но для этого мне понадобится второй сокет для обоих клиентов, потому что приемник и отправитель являются двумя потоками. Другая проблема заключается в том, что происходит, когда пакет с длиной данных теряется, а пакет данных считается длиной.

Может ли кто-нибудь помочь мне в реализации этого?

(TCP это не решение, потому что я хотел бы сделать UDP перфорирования)

+1

Тот факт, что вы любите делать перфорирование отверстий UDP, не является основанием для того, чтобы не использовать TCP, а тот факт, что есть два потока, не является основанием для требования второго сокета. – EJP

ответ

0

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

Вот почему UDP должен только использовать, если потеря пакетов не подходит для приложения.

+0

Спасибо за ваш ответ, но это мне не помогает. Мне нужен soltuion для UDP, потому что я делаю перфорирование отверстий UDP. – Geosearchef

0

Возможно, вам стоит работать с порядковыми номерами. Если создается новое сообщение, отправьте его вместе с порядковым номером. Если другой одноранговый узел обнаруживает отсутствующий порядковый номер, он должен попытаться запросить отсутствующие сообщения от другого партнера. Конечно, вы также должны иметь возможность обрабатывать, когда порядковый номер просто больше не доступен или постоянно терпит неудачу, ограничивая повторы и используя правильные тайм-ауты. Кроме того, другой одноранговый узел может ответить с «порядковым номером, недоступным».

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

Упрощенный, TCP решает это, сохраняя пакеты в буфере: пакеты удаляются из буфера, если другой партнер подтвердил прием. Другой одноранговый узел может запросить повторную отправку буфера, если он обнаруживает недостающие пакеты. Чтобы обнаружить это, приемник также использует буфер. Если буферы заполнены, передача пакетов приостанавливается. Вот почему вам нужны более крупные буферы, чтобы поддерживать конвейер высокоскоростных линий с большой задержкой (например, спутниковых каналов) и использовать связь при максимальной пропускной способности. Так как это не то, что вам нужно, а так как ваши единственные сообщения с единственным дескриптором, вы можете упростить это: ваш буфер - это полная история чата с синхронизированным счетчиком последовательностей, и вам не нужна пропускная способность, просто надежная передача.