Вероятно, что ваши TCP и RUDP ссылки будут нарушены вашей средой, поэтому тот факт, что вы используете RUDP, вряд ли поможет вам;скорее всего, будут времена, когда никакие дейтаграммы не смогут пройти ...
В действительности вам нужно убедиться в том, что a) вы можете обрабатывать количество подключенных клиентов, b) протокол вашего приложения может обнаружить достаточно быстрокогда вы потеряли связь с клиентом (или сервером) и c) вы можете обрабатывать необходимое переподключение и поддерживать состояние сеанса кросс-соединения для клиентов.
Пока вы имеете дело с b) и c) itна самом деле не имеет значения, если связь продолжает разрываться.Удостоверьтесь, что вы разрабатываете протокол приложения так, чтобы вы могли делать вещи в короткие партии;поэтому, если вы загружаете файлы, убедитесь, что вы отправляете небольшие блоки и что протокол приложения может возобновить передачу, которая была прервана на полпути;Вы не хотите, чтобы 99% проходили через передачу 2 ГБ, теряли соединение и должны были начинать заново.
Для этого вашему серверу необходим какой-то кэш состояния сеанса клиента, в котором вы можете хранитьлогическое состояние соединения клиента за пределами жизни самого соединения.Проектируйте с самого начала, чтобы ожидать, что данный сеанс будет включать несколько отдельных соединений.Состояние сеанса, возможно, должно иметь какое-то время ожидания, поэтому, если клиент уходит на длительное время, он не продолжает потреблять ресурсы на сервере, но, честно говоря, это может быть просто случай сохранения состояния на диск послекакое-то время.
Таким образом, я не думаю, что выбор транспорта имеет значение, и я хотел бы начать с TCP, по крайней мере, для начала.Что действительно важно, так это возможность управлять состоянием сеанса вашего клиента на сервере и учитывать тот факт, что клиенты будут регулярно подключаться и отключаться.