Работа с потоковым сервером

Question

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

Проблема заключается в чтении данных на стороне клиента. Как создать клиент для обработки данных без его синхронизации? Если я отправляю подтверждение от клиента на сервер, я теряю скорость параллелизма на стороне сервера. Как я могу написать/спроектировать клиента для быстрой обработки входящих данных? Нужно ли мне реализовать очередь на стороне клиента?

Answer 1

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

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

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

Если вы не хотите, чтобы эта цена RTT, вы неизбежно будете иметь, чтобы либо:

• для клиента, чтобы запросить более одной партии в то время. Для этого вы можете использовать протокол с метками, например IMAP: клиент отправляет сразу несколько заданий на один сокет, каждый со своим собственным тегом. Сервер отвечает на каждый запрос с тегами в заголовке каждого ответа, чтобы клиент знал, какой ответ идет с каким запросом. Когда клиент видит «достаточные» ответы, он отправляет больше запросов. Клиент получает возможность контролировать количество запросов одновременно. Если клиент допускает только один за раз, это вырождается в простой случай ACK с ценой RTT.
• для того, чтобы сервер немного опережал клиента, отправив несколько ответов клиенту до того, как клиент подтвердил первый. После того, как труба будет заполнена до максимального количества неподтвержденных заданий, которые сервер хочет разрешить, он ждет подтверждения и отправляет один дополнительный ответ на задание для каждого подтверждения, которое он получает от клиента. Если сервер разрешает только одно выдающееся задание, это вырождается в простой случай ACK, как указано выше. Если сервер разрешает слишком много неподтвержденных заданий за раз, это вырождается, просто заполняя буферы TCP и рассчитывая на управление потоком TCP, чтобы заблокировать сервер, пока клиент не будет готов принимать больше данных.