Основы Java Socket Server

Question

Для реализации сервера сокетов Java производственного уровня, о каких потенциальных ошибках я должен знать?

На данный момент у меня есть базовая структура кода, использующая классы ServerSocket и Socket core java.net. Сервер ждет клиента и создает для него новый поток.
Мне было интересно, так ли это, или есть ли другие вопросы, которые я должен рассмотреть, прежде чем запускать код в дикой природе.

Несколько вещей, о которых я думал, имея свои ограниченные знания и опыт:

1. Обнаружение отключения клиента и освобождение ресурсов клиента.
2. Пул соединений, это необходимо или я должен придерживаться существующего дизайна.
3. Мониторинг сервера, ведение журнала и устранение ошибок и т. Д.
4. Перейти с готовым фреймворком, как Apache Mina .. ??

Что говорит ваш опыт? ...

Answer 1

Я думаю, это зависит от ваших вариантов использования. Но некоторые мысли:

Готовые фреймворки - хороший путь. Как вы обнаружили, здесь есть над чем подумать. Увидеть ниже. Некоторые возможности (которые реализуют очень разные стратегии) ​​- это Jini (основанная на обнаружении инфраструктура, ориентированная на восстановление) или системы массового обслуживания (которые предлагают отличную развязку клиент / сервер и транзакционность - на основе JMS и / или на основе AMQP)

Объединение является серьезной проблемой. Это предотвратит остановку вашего сервера перед лицом слишком большого количества клиентов. Можете ли вы использовать Java ExecutorService ?

Как вы можете контролировать этот сервер? Можете ли вы использовать JMX и JConsole ? Если вы можете, я бы сказал, что это хороший первый шаг.

Что произойдет, если ваш сервер выключится? Будут ли у ваших клиентов возможность автоматического переподключения? Повторить их невыполненные запросы? Является ли хорошей идеей повторить запрос (т. Е. Идемпотентно)?

Что вы транспортируете между клиентом и сервером? Являются ли они сериализованными классами Java? Если это так, вы гарантировали, что простая перекомпиляция сервера не требует перекомпиляции клиентов (через serialVersionUid s). Если вы переносите строки и конвертируете в байтовые массивы (общий сценарий), используют ли клиент и сервер одинаковую кодировку символов? Если вы не уверены в кодировке, прочитайте this и (возможно) примените ту же самую кодировку клиент / сервер с помощью смешанно названного свойства file.encoding.

Как и в случае распределенных вычислений, рассмотрим Ошибок распределенных вычислений Питера Дойча .

Answer 2

Я был бы склонен просто использовать существующую библиотеку, чтобы сделать все это для вас. Возможно, 2 основных из них - это Apache MINA и JBoss Netty, последний (как сообщается) работает быстрее и не подвержен ошибкам нехватки памяти. Посылка MINA асинхронна в очередь, которая сбрасывается другим потоком, поэтому вполне возможно получить OoM, даже если вы осторожны. У них есть JIRA об этом IIRC.

В качестве альтернативы используйте HornetQ , который построен поверх Netty, но также предоставляет JMS-фасад в клиентском API, поэтому вы можете запустить сервер обмена сообщениями в процессе, с которым вы можете взаимодействовать согласно JMS. Очень удобно на самом деле.