Клиент-сервер шаг — за — шагом, от однопоточного до многопоточного (Client-Server step by step)

[Suvitruf]

Вы забыли 5 пункт: выбросить свой велосипед и использовать что-нибудь вроде Netty.

[OlegMercenery]

Смысл публикации в том что бы помочь начинающим разбираться в архитектуре клиент-серверных приложений, а не сделать свой «велосипед». Спасибо за Ваше мнение!

[Suvitruf]

No offense, но я бы никому не рекомендовал учить архитектуру клиент-серверных приложений по этой статье.

[OlegMercenery]

Всегда открыт к конструктивной критике…

[OlegMercenery]

Правильнее рекомендовать что то другое более продуктивное, лучшее и информативное.

[AndreyRubankov]

Конструктив:
1. Все исходники следует перенести на GitHub (или подобный)
2. Сделать больше упор на Архитектуру с картинками, переходами и анализом каждого из вариантв, нежели на сам код.
3. Если хотите разобрать тему полностью, то следует сразу создать заготовку под серию статей:
3.1. Old IO (java.net) — ваши однопоточный и многопоточный серверы: синхронные с кучей потоков
3.2. New IO (java.nio) — асинхронный сервер
3.3. netty.io — рассмотреть архитектуру и показать пример

Сейчас Вы рассматриваете ту часть java network, которая уже морально устарела. Old IO следует рассматривать только в ознакомительных целях, а любые продакшн решения должны строиться на NIO.

[OlegMercenery]

1. Исходники на GitHub е в куче лежат, сделаю отдельный репозиторий для этой статьи и прикреплю ссылку позже, спасибо.
2. В сети очень много таких картинок, но они дают абстрактно теоретический эффект, а когда запущен работающий код с подробным комментированием практически понимаешь как всё что на картинках нарисовано исполняется.
3. — супер, так и сделаю! Спасибо за подсказку!

[AndreyRubankov]

В интернете есть куча информации обо всем. Даже про java sockets.

Код — это хорошо, но чтобы понять всю суть и все проблемы по коду, нужно будет потратить много времени.
Но «картинка» архитектуры + описание — это лучший способ подачи информации о том, как все должно и будет работать.

При построении этой «картинки» все проблемные места всплывают сами по себе. Если схема получается сложной — значит в архитектуре есть проблемы, а в процессе объяснения схемы сразу всплывают все костыли («вот этот аппендикс нужен для...»).

Совет с картинками применим вообще к любому проектированию, а не только к данной статье.

[dvemnt]

Это код с комментариями, а не публикация, при всём уважении.

[OlegMercenery]

Точно! Я так там и написал, что лучше понять эту структуру можно только запустив этот самый код и изучив выводы на консоль всех этапов работы и взаимодействия клиента и сервера. В этом можно сказать вся суть публикации. Спасибо, что вы акцентировали на этом внимание!

[Cobolorum]

Автор больше не пиши.

[OlegMercenery]

Спасибо за позитвные слова ибо таких мало. Можно по ключевым пройтись? Судя по количеству просмотров — людей много интересуется, есть возможность им лучше помочь, ну если есть конечно свободное время и желание!?

[OlegMercenery]

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

[alek_sys]

Потоки: для того чтобы не перепутать что именно подразумевается под потоком я буду использовать существующий в профессиональной литературе синоним — нить, чтобы не путать Stream и Thread, всё-таки более профессионально выражаться — нить, говоря про Thread.

Я бы все таки порекомендовал переводить thread как «поток», «нить» это чаще всего fiber, который не совсем поток. По крайней мере, раньше во многих книгах использовалась именно такая терминология. Ну, либо вообще не переводить.

[OlegMercenery]

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

[avost]

В какой ещё профессиональной литературе? На заре времён, из которых вы откопали этот нафталиновый пример? Не стОит, тот поезд давно под откосом.

[Neuyazvimy1]

Видно что это ваш первый сервер. Думаю каждый начинающий серверный разработчик написал бы что то типа наподобие вашего творения. Лучше было бы еще пару серверов написать и уже тогда браться за статью.
Советую реализовывать сервер с rpc принципом. А еще лучше как советовали выше использовать netty.
А вообще классно было бы использовать связку netty+protobuf.
https://en.wikipedia.org/wiki/Remote_procedure_call
https://en.wikipedia.org/wiki/Reactor_pattern
Удачи в серверной разработке.

[OlegMercenery]

Очень полезный комментарий, благодарю. Есть понимание следующего шага в направлении написания серверных приложений. Просто начинающему наверное сразу браться за netty+protobuf отобьёт всё желание разбираться дальше — слишком сложно будет.
Друзья! Прошу писать свои мысли в подобном виде, со ссылками и конкретными предложениями!

[Suvitruf]

Если говорить про netty, то базовые примеры там даже проще и понятнее описаны, чем в вашей статье.

Но, опять же, проблема не в коде, а подходе. Объяснять базовые вещи в клиент-серверной архитектуре надо не кодом, а схемами. Как только человек поймёт теоретические принципы, то написать пример уже на любой языке будет просто.

[OlegMercenery]

Схема появляется за 5 секунд по запросу в google а как процессы протекают внутри кода мне например по UML схеме не понятно, программисту нужно понимать что за чем идёт в потоке выполнения программы, ну и конечно схема нужное дело тоже.

[KislyFan]

Ребятки, а есть такой же тутор только для .net с блекджеком и Queue ?