Как лучше реализовать? (работа с сетью, TCP/UDP)

Реализовать то что именно?

PS: Сервер все-таки обычно не спрашивает, он обычно сам отвечает на запросы клиентов.

вопрос в том как реализовать сношение клиента с сервером. делать ли это по UDP или нет?

Скажите, зачем вам UDP?

затем что нет гарантии что сервера работают.

>затем что нет гарантии что сервера работают.
udp не гарантирует, что будет передача данных. Это протокол без соединения, а не для случаев когда серевера не работают.

можешь multicast если хочется реального извращения

multicast в данном случае именно извращение. На мультикаст подписываются клиенты, а не сервера. И в данном случае это вообще как 5 колесо.

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

>за тысячные доли секнуды, если возможно. опять же, возможно что один сервер стоит в том же датацентре а второй в другой стране например.
Сделать запрос-то всё равно придётся. Хотя если нужна максимальная скорость, то udp конечно лучше.

>> Думаю сделать UDP.

ненадежно
негарантированно

C udp всё равно придётся каким-то макаром понимать что больше пакетов не придёт и клиент умер. Здесь ситуация ничем не отличается от tcp. А узнать работает ли клиент или нет - вам тоже придётся вне зависимости от протокола. Вы же не знаете этого сразу. То есть как минимум вам нужно - установить соедиение, получить или отправить данные, завершить соединение. И здесь разницы принципиальной в udp или tcp нет. Разница в том, что в случае udp вам ещё придётся гарантировать невредимость данных. А в случае tcp всё само делается. Если речь идёт о возможности оправки мегабайт важных данных, то udp можно рассматривать только совместно с велосипедами, гарантирующими сохранность и порядок доставки.

>UDP

DATA может быть БОЛЬШИМ, вплоть до десятков мегабайт

Ты подумал над тем, что будешь ручками реализовывать передачу таких данных поверх UDP? Напоминаю: максимальный размер IPv4-пакета — 64kb вместе со времи заголовками. UDP хорош только передачи небольшого объема информации, дальше начинаются проблемы (уже при более чем 1.2kb данных в пакете).

угу. придётся делать свою библиотеку для принятия длинных пакетов по частям.

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

измерь latency от клиента до сервера при TCP и UDP. Если клиент и сервер расположены дальше, чем 1-2 маршрутизатора, разницы практически не будет. а tcp много вкусных плюшек предлагает.

В только сначала погонятей тестовые примеры, просто раньше, современные ядра я особо не изучал, буфер UDP сокета был достаточно небольшой (64 или 128 кбайт) и все, что в него не влазило, просто сбрасывалось. То есть когда загрузка большая и процессу не сразу удаётся получить квант времени, то при большом потоке UDP-данных он просто не может получить все пакеты, а с tcp было лучше. То есть просто на гигабитной сети попробуйте с одной стороны отправить 10 Мбайт данных, а с другой принять и посчитать, сколько пакетов потерялось.

Возможно, вам придётся наворачивать что-то типа DNS, короткие ответы по UDP, а большие объемы данных (трансфер зоны) по TCP. ИМХО, при передаче 10 и более Мбайт уже досточно легко получить смерть клиента или обрыв канала связи и никаких тысячных долей секунды в этом случае :)

> понимаешь, у меня нет времени устанавливать соединение с сервером и потом ждать всяких таймаутов, всё должно происходить как можно быстрее. за тысячные доли секнуды,

И ты поэтому собираешься гнать десятки мегабайт по ненадежному протоколу?

На SCTP посмотри.

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

Ха-ха. Roundtrip померяй - он может оказаться 3-4мс, это значит, что даже в одну сторону пакет за 1мс не дойдет.