Дизайн сервера блокировки без сохранения состояния

Question

Небольшая помощь, пожалуйста.

Я проектирую сервер без сохранения состояния, который будет иметь следующую функциональность:

1. Клиент отправляет задание на сервер.
2. Клиент заблокирован, пока сервер пытается выполнить задание.
3. Сервер создаст один или несколько потоков для выполнения задания.
4. Задание либо завершено, либо истекло, либо не выполнено.
5. Создается соответствующий ответ (на основе результата), клиент разблокируется, и ответ передается клиенту.

Вот то, о чем я думал до сих пор.

1. Клиент отправляет задание на сервер.
2. Сервер назначает задание ID, помещает задание в очередь, а затем помещает клиента в другую очередь (где оно будет заблокировано).
3. Иметь пул потоков, который будет выполнять задание, извлекать результат и соответствующим образом создавать ответ.
4. На основе идентификатора выбрать клиента из очереди (тем самым разблокировать его), дать ему ответ и отправить его.

Шаги 1,3,4 кажутся довольно простыми, однако любые идеи о том, как поставить клиента в очередь и затем заблокировать его. Кроме того, любые указатели, которые помогли бы мне проектировать этого щенка, будут оценены.

Приветствия

Answer 1

Зачем вам блокировать клиента? Похоже, что было бы легче немедленно вернуться (почти) (после выполнения первоначальной проверки, если таковые имеются) и дать клиенту уникальный идентификатор для данной работы. После этого клиент сможет либо опросить, используя указанный идентификатор, либо, возможно, предоставить обратный вызов.

Блокировка означает, что вы держитесь за сокет, который явно ограничивает максимальное количество клиентов, которых вы можете обслуживать одновременно. Если это не имеет значения для вашего сценария, и вам абсолютно необходимо заблокировать (возможно, вы не можете контролировать клиентский код и не можете заставить его опрашивать?), Нет смысла создавать потоки для выполнения задания, если вы не можете фактически разделить его на параллельные задачи. В этом случае единственной «очередью» будет та, которая хранится в общем пуле потоков. Рабочий процесс в основном будет:

1. Создание пула потоков (например, ThreadPoolExecutor )
2. Для каждого запроса клиента:
   1. Если у вас есть какие-то части задания, которые вы можете выполнять параллельно, делегируйте их в пул.
   2. И / или делать их в текущем потоке.
   3. Дождитесь завершения рабочих заданий в пуле (если применимо).
   4. Вернуть результаты клиенту.
3. Завершение работы пула потоков.

Идентификаторы не нужны сами по себе; хотя вам может понадобиться использовать какую-то защелку для 2.1 / 2.3 и выше.

Время ожидания может быть немного сложным. Если вам нужно, чтобы они были более или менее точными, вам нужно будет оставить основной поток (тот, который получил запрос клиента) свободным от работы и просигнализировать об отправленных частях задания (установив флажок), когда истечет время ожидания, и немедленно вернуться , Вам придется периодически проверять указанный флаг и прекращать выполнение, когда он перевернут; Затем пул восстановит поток.

Answer 2

Тайм-ауты будут несколько хитрыми и будут иметь скрытые ошибки, но основной дизайн, казалось бы, прост: напишите класс, который принимает Socket в конструкторе. в socket.accept мы просто выполняем новую реализацию обработки сокетов, с большим предвидением и планированием масштабируемости или, если это стендовый тестовый эксперимент, то класс обработки сокетов просто переходит к обработке данных, а когда он возвращается, у вас есть некоторые своего рода логическое или числовое для состояния или чего-либо, удобное место для null btw, и ether записывает успех в поток вывода из сокета или информирует клиента о времени ожидания или о том, какие потребности вашего бизнеса

Если вам нужен масштабируемый, эффективный дизайн для длительных тяжеловесов, перейдите непосредственно к nio ... одноразовым ручным кодированным решениям, которые я описываю, вероятно, не будет хорошо масштабироваться, но обеспечит фундаментальную концептуальную основу для nio дизайн код-правильной работы.

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

Answer 3

Как вы общаетесь с клиентом?

Я рекомендую вам создать объект, представляющий каждое задание, которое содержит параметры задания и сокет (или другой механизм связи) для достижения клиента. Затем пул потоков отправит ответ для разблокирования клиента в конце обработки задания.