Сокеты Java - убедитесь, что одно клиентское соединение обслуживается раньше других

Вам нужно будет реализовать какой-то алгоритм планирования/качества обслуживания. В самой простой форме это действительно может быть просто «пока есть данные в специальном сокете, не беспокойтесь о других сокетах».

Эта простая модель может быть достигнута, например, с двумя списками:

1. Один список специальных розеток
2. Один список обычных сокетов.

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

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

Как отметил @Konerak, вам придется реализовать некоторую форму QoS.

Вы можете попытаться определить тип данных для ваших сообщений, с которыми вы их инкапсулируете, а затем добавить тег, чтобы отметить, что определенное сообщение имеет определенный вид (например, ваш специальный сокет). Затем, когда сервер получает сообщение, вы можете вставить сообщение в очередь, где вы начнете выполнять. Сначала выполните все сообщения, помеченные как «специальные» (или то, что вы хотите использовать), а затем перейдите ко всем сообщениям без тега. Очередь (FIFO) гарантирует, что все сообщения обрабатываются по мере их поступления. Обязательно ознакомьтесь с методом Peek очереди ( http://download.oracle.com/javase/1,5.0/docs/api/java/util/Queue.html).

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

Вы также можете сохранить метод Thread per Client. Это вполне нормально в небольшой среде, где подключено всего несколько клиентов, но по мере того, как вы начнете масштабироваться до больших чисел, вам, возможно, придется подумать об использовании NIO. Но, как я уже сказал, оба подхода являются допустимыми, каждый со своими плюсами и минусами.

Просто идея и пара моментов для размышления.