Комментарии 32
Когда начинающий пишет для начинающих — получается так себе…
Вы бы лучше вместо кода показали архитектуру на UML, было бы очень интересно и познавательно.
НЛО прилетело и опубликовало эту надпись здесь
Архитектуру обязательно покажу, позже, спасибо за совет. Но смысл публикации в том чтобы познакомить с работой этого механизма в реальной работе приложения, а не в теории.
Фреймворки — это просто замечательно и dependency injection — тоже нужная и полезная штука! Особенно когда понимаешь что под капотом!
Предлагаю развить тему — как бы это было в современном программировании! Прошу поделиться более конкретными предложениями и опытом, если у вас его больше!
Все профессионалы не родились сразу такими — они тоже были начинающими, или бывает какой то другой путь?? Расскажите пожалуйста.
Фреймворки — это просто замечательно и dependency injection — тоже нужная и полезная штука! Особенно когда понимаешь что под капотом!
Предлагаю развить тему — как бы это было в современном программировании! Прошу поделиться более конкретными предложениями и опытом, если у вас его больше!
Все профессионалы не родились сразу такими — они тоже были начинающими, или бывает какой то другой путь?? Расскажите пожалуйста.
Правда если есть конкретные замечания — я прошу их озвучить, тогда я подправлю недочёты и публикация поможет людям больше!
конретные замечания? Предложенные решения — были современны и актуальны примерно в 94-98м годах прошлого века.
Лучше — вопросы к размышлению
1) Сколько потоков запустит сервер, если к нему придет 1000 клиентов? Если 1000 — то на каком железе это могло бы работать без деградации производительности? На обычном — так точно нет.
2) Если 10 поточный клиент захотел всеми своими 10 потоками послать 10 запросов, то сколько пакетов по сети он пошлет? Если 10, то как это будет масштабироваться при увечении количества клиентских потоков?
Поизучайте что такое мультиплексирование запросов, как устроен современный протокол, например HTTP2, как пишутся многопоточные сервера, держащие 10 тыс коннектов на обычных 16 ядерных серверах. Как им удается обслуживать до миллионов запросов в секунду — вы, посмотрите может ли сетевая карточка даже 10GB пропустить миллион пакетов в секунду…
Лучше — вопросы к размышлению
1) Сколько потоков запустит сервер, если к нему придет 1000 клиентов? Если 1000 — то на каком железе это могло бы работать без деградации производительности? На обычном — так точно нет.
2) Если 10 поточный клиент захотел всеми своими 10 потоками послать 10 запросов, то сколько пакетов по сети он пошлет? Если 10, то как это будет масштабироваться при увечении количества клиентских потоков?
Поизучайте что такое мультиплексирование запросов, как устроен современный протокол, например HTTP2, как пишутся многопоточные сервера, держащие 10 тыс коннектов на обычных 16 ядерных серверах. Как им удается обслуживать до миллионов запросов в секунду — вы, посмотрите может ли сетевая карточка даже 10GB пропустить миллион пакетов в секунду…
Спасибо за дополнительную тему. Данное решение с доработками, понятно, имеет место в жизни, а тем более актуально для объяснения человеку не знакомому с архитектурой познакомиться с основными принципами и посмотреть на предстоящие проблемы при разработке таких серверов. И этот комментарий будет ценным если автор даст какую либо ещё информацию — (ссылку, автора, название книги/публикации) и тогда комментарий будет иметь смысл. Ещё раз повторюсь я здесь не реализовываю высоконагруженную систему, для её понимания есть более квалифицированные источники(кстати прошу поделиться ими, всем это будет полезно и интересно).
Если 1000 — то на каком железе это могло бы работать без деградации производительности? Если 1000 — то на каком железе это могло бы работать без деградации производительности? На обычном — так точно нет.
Как это мило, когда кого-то обвиняют в неактуальности ретранслируя неактуальные мифы про 1000потоков из 90х.
держащие 10 тыс коннектов
10к держат хелворды на атоме.
Как им удается обслуживать до миллионов запросов в секунду
Поподробнее об этом.
Как это мило, когда кого-то обвиняют в неактуальности ретранслируя неактуальные мифы про 1000потоков из 90х.
Мифы? Ну посмотрите на то как работает многопоточный Apache в 2019м году.
Количество потоков ограничено лишь лимитами. С легкостью запустит 500. А если разрешите больше — и 1000 запустит. Или будете доказывать что Apache не актуальный?
Насчёт миллионов запросов — а какие подробности интересуют?
Ну с верхнего уровня — xeon 32ядра, 128GB памяти, 10GBit сеть — довольно типичный блейд сервер.
В современном программировании на яве это всё "муветон". Никто в трезвом уме не станет выделять целый тред на соединение. Сервер начнёт загибаться на сотнях одновременных соединений. Про миллион вообще молчу.
ServerSocket является Closeble, потому вы в трае его объект и создаете, а затем зачем-то руками закрываете
Нить — это fiber, но никак не thread.
А какой смысл эту статью и тут, и на хабре (https://habrahabr.ru/post/330676/) размещать было?
А есть аналогичные статьи по C++?
Статьи продублированы чтобы услышать больше полезных комментариев по теме.
Спасибо за делИгатов! Исправлено.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за критику! Ссылка на GitHub добавлена в публикацию.
По второму вопросу не могу согласиться Java Concurrency in Practice уважаемого Брайна Гоэтца на выдержку из которой вы дали ссылку написана гуру и отредактирована командой профессионалов, как программистов так и верстальщиков, так что мне конечно лестна попытка сопоставить моё скромное творение с таким шедевром, но пока рано… Кроме того книгу в нормальном русском переводе я ещё не видел, а на английском не все люди могут осилить…
Теперь по поводу оформления и пояснений — прошу добавить что конкретно плохо и где что не пояснено! Без абстракций, тогда я исправлю статью и все останутся довольны.
По второму вопросу не могу согласиться Java Concurrency in Practice уважаемого Брайна Гоэтца на выдержку из которой вы дали ссылку написана гуру и отредактирована командой профессионалов, как программистов так и верстальщиков, так что мне конечно лестна попытка сопоставить моё скромное творение с таким шедевром, но пока рано… Кроме того книгу в нормальном русском переводе я ещё не видел, а на английском не все люди могут осилить…
Теперь по поводу оформления и пояснений — прошу добавить что конкретно плохо и где что не пояснено! Без абстракций, тогда я исправлю статью и все останутся довольны.
Брат, чего ты пытаешься добиться? Заметил, большей популярностью на хабре пользуются статьи маркетологов? Итак, ты опубликовал «велосипед» ты пытался пояснить, что это статья интересна новичкам, но это давно уже ничего не значит, сейчас здесь котируется только маркетинговый буллшит и статьи с модными названиями вроде docker (а мне так и хочется спросить, что стало с адептами openvz)? nosql (для тех кто sql не осилил) и прочее. При этом они активно забывают, что являясь прикладными программистами всей этой сетевой фигни они понятия не имеют ни о протоколах передачи данных ни о прочем, что выходит за рамки стандартных библиотек. Вот ей богу уже пару раз встречал ведущих WEB-програмистов верящих в протокол MAIL (который php mail();) и тех, которые считают, что CDO наше все, и если оно работает некорректно, то в этом конечно же виноваты администраторы почтового сервера, но никак не программист выбравший стандартную библиотеку, но понятия не имеющий почему она начинает передавать данные еще до того как установит tls-соединение.
Спасибо за моральную поддержку! Я просто помню, как сам искал полгода назад аналогичные статьи, которые бы могли разъяснить мне всё понятным человеческим языком. Такие статьи мне очень помогли. Поэтому — это мой cashback энтузиастам за их труды, благодаря помощи которых я имею представления о Java. Ну и надеюсь, что публикация поможет врубиться в эту довольно тяжёлую тему. Наверное запущу голосование — «Кому помогла статья?».
Ну ладно, если кому-то интересно, вот мой «велосипед» позволяющий использовать последовательный порт для нескольких протоколов одновременно Raw, modbus-tcp-2-modbus-rtu, и modbus-tcp в протокол ивтм7-м3/ивтм7-н Проверено в работе на linux amd64/armel/armhf должно работать также под windows в в сочетании с nssm. И да tcp-сервер на golang там присутствует.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Клиент-сервер шаг — за — шагом, от однопоточного до многопоточного (Client-Server step by step)