Вообще-то правильные мальчики ставят управляемые коммутаторы везде! И настраивают на них DHCP-snooping. Что бы неповадно было адреса-маки менять.
Ибо сеть должна быть контролируемая, и хрен-с-горы не портил общий прон.
ValdikSS, Ваши слова - елей, которые все портит подчинительный союз "если". И напомните мне, когда это "новичку чайнику" удавалось не просрать домен и IP в первые же часы установки SMTP, а потом долго выкарабкавыться из спам-листов.
Возможно здесь есть еще с десяток "если" и "но"?
Speakermen, касательно рисунка, не всегда есть объектный подход к программированию, есть еще и процедурный, а еще и функциональный, а еще и событийный, и смесь всех сразу или понемногу :)
Конечно же объектный сейчас превалирует, но нужно помнить, ядро линукса да и большинство юниксов написано в процедурном стиле.
Speakermen, алгоритмы, это просто рецепты.
Хотим приготовить борщ, кладем определенный набор ингредиентов. Хотим чизкейк - он делается вот так.
В программировании все в принципе похоже, и это - алгоритмы.
Хотим хотим свяэанеый список, пожалуйста. Хотим сортировку - вот так.
Самый большой сборник алгоритмов описал Дональд Кнут. Рекоменую купить его "искусство программирования", все четыре тома., и вдумчиво читать на ночь в течении нескольких лет!
Большинство алгоритмов уже не нужно реализовывать самостоятельно, их собрали в базовые библиотеки языков и протестировали, подключаем нужное и пользуем.
Хотелось бы дополнить. В некоторых базах данных еще и зависит от типа блокировки - таблица или запись. Но PK гарантированно будет разный. А по хорошему - автоинкремент зло лютое.
Вообще-то показывают обычно несколько последних (10-20) сообщений по времени, а на клиенте, в куках или webstorage (вообще офигительно!) хранят id последнего сообщения, обычно это unix timestamp (число). Если клиент не запростил ID последнего, то дают последние 10-20, по timestamp удобно выбирать из базы данных, или кафки :)
s, на фронте достаточно простого javascript/fetch, и может быть promises, если хотим асинхронности https://learn.javascript.ru/fetch (это и для SSE и для LongPool).
Для WS есть куча оберток, но можно и напрямую - https://learn.javascript.ru/websocket . В современном JS все достаточно удобно.
Касательно отличия опроса, от "длинного опроса". Опрос - это когда делаем постоянные запросы на сервер и тут-же получаем ответ. Это хреново, жрет кучу ресерсов и генерирует кучу трафика.
Long pooling - это когда подключились к серверу и сервер не дает ответа, до тех пор, пока у него что-то не перещелкнет (например не появится событие для конкретного клиента), тогда сервер генерирует ответ и закрывает соединение. Клиент заново подключается к серверу. На стороне сервера нужно просто иметь какой нибудь Hashtable для хранения открытых запросов - https://russianblogs.com/article/92601645700/
Для SSE - тоже нужен отдельный сервлет, но переподключаться к серверу не нужно, на стороне клиента можно использовать EventSource - https://learn.javascript.ru/server-sent-events (или тот-же fetch)
Я за SSE или LongPooling, но нужно обязательно на стороне сервера увеличить одновременное количество коннектов!, ибо каждый клиент будет держать открытое соединение).
Ибо сеть должна быть контролируемая, и хрен-с-горы не портил общий прон.