Предоставлять пользователям возможность выбора между UDP и TCP?

Question

После изучения различий TCP / UDP всю неделю я просто не могу решить, какой из них использовать.Я должен отправить большое количество постоянных данных датчика, в то же время отправляя важные данные, которые не могут быть потеряны.Это сделало меня идеальным разделением для использования обоих, затем я прочитал статью (http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM), в которой говорится, что использование обоих приводит к потере пакетов / производительности в другом. Возникает ли какая-либо проблема, если я позволю пользователю выбирать, какой протоколиспользовать (если я программирую обе стороны сервера) вместо того, чтобы выбирать сам? Есть ли у этого какие-либо недостатки?

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

Answer 1

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

Попробуйте использовать TCP и измерьте свою производительность. Если все в порядке, и вы не ожидаете серьезных проблем с масштабированием, просто оставайтесь с TCP.

Answer 2

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

Answer 3

ОП говорит:

... отправка важных данных, которые нельзя потерять.

Следовательно, TCP по определению является правильным ответом по UDP.

Помните, что "U" в UDP означает "ненадежный"

Re:

Единственное другое решение, которое я придумал, - это использовать UDP, а если кажется, что потери пакетов слишком велики, переключитесь на TCP (на стороне клиента).

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

Answer 4

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

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

Может быть, вам будет достаточно ограничить использование TCP, чтобы не заполнить полосу пропускания?

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

Постоянные данные датчика: UDP. Важные данные, которые нельзя потерять: TCP.

Answer 9

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