alex_ak1, тогда берете цепочку, желательно чтобы оба хоста были в локальной сети. И последовательно проходите путь, и смотрите на загрузку портов , сбросы пакетов, загрузку коммутаторов и прочие ошибки. Ну и попробуйте попинговать между собой эти два хоста, есть ли джиттер, какая задержка, потери пакетов.
Кирилл, Конкретные учебники посоветовать не могу. Но обычно советую следующее:
У Cisco есть трек сертификации CCNA - CCNP -CCIE(в упрощенном виде). Собственно для углубленного изучения вам нужен CCNP routing and switching. Там три экзамена вас интересуют два Routing , Switching.
Третий Troubleshooting. Для понимания он не особо нужен. Смотрите книги которые готовят к ССNP по этим двум экзаменам.
Kormans, это два разные вектора развития. Они где то соприкасаются, но набор знаний и акцентов различный. Поэтому для изучения сетей достаточно знать, что такое процессор, как поставить windows, и где в операционной системе забиваются настройки сети.
Kormans, да сетевик это сетевой администратор или сетевой инженер. Инженер подразумевает более глубокие системные знания чем администратор, но в целом для всех остальных это пофиг.
Да сервера это системные администраторы, а взаимодействие это сетевики.
Kormans, есть профессия сетевой инженер, полностью заточена на применение этих знаний.
Если другие области ИТ, это хороший столб в понимании возникающих проблем, и в построении архитектуры вашей системы.
Быстро денег на этих знаниях срубить не получиться, нужен хороший опыт прежде чем вы станете ценны, как сетевик. Опять же из-за специфичности знаний, вы можете решать проблемы в области взаимодействия серверов и рабочих станций по договоренности. Можете прорабатывать архитектуры на заказ.
mrrayman, разбор технической проблемы, требует проверки определенных моментов. Без этих шагов можно потыкать в небо пальцем, эффект будет тот же. Приоритет вы определяете сами. Проблема же ваша.
Сергей Гультяев, Отдельный сервер у вас выступает централизованной точкой контроля. На сервере вы можете собирать подробные логи всех действий администратора, и например делать снимки раз в пять секунд. Плюс одна точка для администрирования учеток администраторов.
Что в принципе решает вашу проблему.
KaizerSX, точного ответа у меня нет , не сталкивался с таким.
Можно попробовывать в @RequestBody сказать что получаешь json объект а не pojo class.
может быть прокатит.
KaizerSX, с большой вероятностью программа выдаст ошибку.
Тут или необходимо в классе описать все поля, какие могут быть. Тогда если в текущем ответе не придет какое то значение , оно в классе примет значение null.
Или что то придумывать. Например не десириализовать ответ, а просто получать объект json , и его разбирать чем нибудь далее.
KaizerSX,
1) Зависит от задач. Вообще spring мощный комбайн , который позиционируется как решение, которое имеет все что нужно для быстрого написания вашего приложения. Поэтому если нет каких то особых требований, то встроенный сериализатор вполне себе подойдет.
2) честно говоря не знаю. надо смотреть что они внутри используют.
KaizerSX, @requestBody указывается, что в теле запроса следует ожидать данные согласно классу plusscode. Spring имеет встроенный десиарилизатор json. поэтому видя json он пытается его преобразовать в data class ккоторый идет после аннотации.
Эта строчка, настраивает параметры ответа.
Условно говоря что в ответе должен быть обязательно параметр somecity в ввиде строки.
Звполнение данными в данном случае происходит тут
SomeCity data = gson.fromJson(somecity, SomeCity.class);
Формируем экземпляр класса SomeCity , который назван data. Формирование производим судя по всему с помощью gson библиотеки. Передаем в метод город "somecity", и класс SomeCity.class.
Не совсем так, серверные операционные системы тоже умеют со своей стороны собирать бондинги.
Поэтому чтобы собрать bond нужно настраивать с двух сторон, со стороны муршрутизатора, и со стороны операционной системы, и все будет работать.