Comments 23
Вы забыли 5 пункт: выбросить свой велосипед и использовать что-нибудь вроде Netty.
Смысл публикации в том что бы помочь начинающим разбираться в архитектуре клиент-серверных приложений, а не сделать свой «велосипед». Спасибо за Ваше мнение!
No offense, но я бы никому не рекомендовал учить архитектуру клиент-серверных приложений по этой статье.
Конструктив:
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.
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.
1. Исходники на GitHub е в куче лежат, сделаю отдельный репозиторий для этой статьи и прикреплю ссылку позже, спасибо.
2. В сети очень много таких картинок, но они дают абстрактно теоретический эффект, а когда запущен работающий код с подробным комментированием практически понимаешь как всё что на картинках нарисовано исполняется.
3. — супер, так и сделаю! Спасибо за подсказку!
2. В сети очень много таких картинок, но они дают абстрактно теоретический эффект, а когда запущен работающий код с подробным комментированием практически понимаешь как всё что на картинках нарисовано исполняется.
3. — супер, так и сделаю! Спасибо за подсказку!
В интернете есть куча информации обо всем. Даже про java sockets.
Код — это хорошо, но чтобы понять всю суть и все проблемы по коду, нужно будет потратить много времени.
Но «картинка» архитектуры + описание — это лучший способ подачи информации о том, как все должно и будет работать.
При построении этой «картинки» все проблемные места всплывают сами по себе. Если схема получается сложной — значит в архитектуре есть проблемы, а в процессе объяснения схемы сразу всплывают все костыли («вот этот аппендикс нужен для...»).
Совет с картинками применим вообще к любому проектированию, а не только к данной статье.
Код — это хорошо, но чтобы понять всю суть и все проблемы по коду, нужно будет потратить много времени.
Но «картинка» архитектуры + описание — это лучший способ подачи информации о том, как все должно и будет работать.
При построении этой «картинки» все проблемные места всплывают сами по себе. Если схема получается сложной — значит в архитектуре есть проблемы, а в процессе объяснения схемы сразу всплывают все костыли («вот этот аппендикс нужен для...»).
Совет с картинками применим вообще к любому проектированию, а не только к данной статье.
Это код с комментариями, а не публикация, при всём уважении.
Автор больше не пиши.
Господа, цель статьи дать первичные знания по основам клиент-сервера, если у вас есть что добавить к публикации или выявленные ошибки в коде или в описании я очень жду конкретных замечаний. Если такие есть — пишите я разберусь и исправлю!
Потоки: для того чтобы не перепутать что именно подразумевается под потоком я буду использовать существующий в профессиональной литературе синоним — нить, чтобы не путать Stream и Thread, всё-таки более профессионально выражаться — нить, говоря про Thread.
Я бы все таки порекомендовал переводить thread как «поток», «нить» это чаще всего fiber, который не совсем поток. По крайней мере, раньше во многих книгах использовалась именно такая терминология. Ну, либо вообще не переводить.
Скорее не переводить — это лучший вариант и я сам использую именно его, но такой вариант так же имеет место быть в профессиональной литературе, и поскольку статья всё таки на русском решил применить этот вариант, чтобы новички акцентировали внимание на том что тут существует некая неоднозначность и стали копать — это тоже будет полезно.
Видно что это ваш первый сервер. Думаю каждый начинающий серверный разработчик написал бы что то типа наподобие вашего творения. Лучше было бы еще пару серверов написать и уже тогда браться за статью.
Советую реализовывать сервер с rpc принципом. А еще лучше как советовали выше использовать netty.
А вообще классно было бы использовать связку netty+protobuf.
https://en.wikipedia.org/wiki/Remote_procedure_call
https://en.wikipedia.org/wiki/Reactor_pattern
Удачи в серверной разработке.
Советую реализовывать сервер с rpc принципом. А еще лучше как советовали выше использовать netty.
А вообще классно было бы использовать связку netty+protobuf.
https://en.wikipedia.org/wiki/Remote_procedure_call
https://en.wikipedia.org/wiki/Reactor_pattern
Удачи в серверной разработке.
Очень полезный комментарий, благодарю. Есть понимание следующего шага в направлении написания серверных приложений. Просто начинающему наверное сразу браться за netty+protobuf отобьёт всё желание разбираться дальше — слишком сложно будет.
Друзья! Прошу писать свои мысли в подобном виде, со ссылками и конкретными предложениями!
Друзья! Прошу писать свои мысли в подобном виде, со ссылками и конкретными предложениями!
Если говорить про netty, то базовые примеры там даже проще и понятнее описаны, чем в вашей статье.
Но, опять же, проблема не в коде, а подходе. Объяснять базовые вещи в клиент-серверной архитектуре надо не кодом, а схемами. Как только человек поймёт теоретические принципы, то написать пример уже на любой языке будет просто.
Но, опять же, проблема не в коде, а подходе. Объяснять базовые вещи в клиент-серверной архитектуре надо не кодом, а схемами. Как только человек поймёт теоретические принципы, то написать пример уже на любой языке будет просто.
Ребятки, а есть такой же тутор только для .net с блекджеком и Queue ?
Sign up to leave a comment.
Клиент-сервер шаг — за — шагом, от однопоточного до многопоточного (Client-Server step by step)