Это вопрос терминологии. Смотря что мы понимаем под интернетом. Если мы рассматриваем www, с его доменными именами, сайтами, и т.п. - они работают на базе IP. Но сам IP не является www. Можно организовать домашнюю локальную сеть, на базе IP, объединяющую бытовые устройства, - будет ли эта сеть интернетом? И да, и нет.
Service discovery не предназначен для маршрутизации и передачи информации. Его задача - предоставлять информацию о нахождении сервисов. Его, в принципе, можно использовать для передачи информации, но тогда у вас получается не одноранговая, а централизованная клиент-серверная система.
Узел 1 хочет отправить сообщение узлу 10. Он обращается к service discovery, и говорит, "дай мне адрес узла 10". Зачем тогда строить маршрут? Он может сразу отправить сообщение узлу 10. Единственное, ему необходимо иметь подключение к этому узлу. Как и ко всем остальным. Мы приходим к 1 случаю - полный граф, все соединены со всеми.
Если хотите использовать service discovery для коммуникации, тогда вам нужно его использовать как коммутационный сервер. Все сервисы подключены к единой точке, отправляют туда сообщения, а service сразу пересылает их получателю, поскольку знает его адрес. Широковещательная рассылка будет очень простой - разослать сообщение всем подключенным узлам. Но неэффективной - множество дубликатов сообщений будет идти по одним и тем же IP адресам в IP маршрутах. Тут уж все зависит от требований.
Для небольших сетей, порядка нескольких сотен, схема сработает, при условии, что service discovery будет достаточно мощный. Но с маштабированием будет не очень - с ростом количества узлов все упрется в пропускную способность центрального сервера.
IP - это не интернет-протокол. Это транспортный протокол, который доставляет пакеты от источника к получателю. Правила маршрутизации здесь задаются физическими устройствами - сетевыми коммутаторами. А уже интернет-протоколы, тот же HTTP, работает на базе IP адресов.
Оверлейная сеть также работает на базе IP адресов, т.е. это верхний уровень. Упрощенно, IP адреса можно рассматривать как физический уровень, а идентификаторы - как логический. Т.е., сеть, объединяющая узлы с идентификаторами, представляет собой некоторое подмножество IP сети.
Скажем так. XML гораздо более выразительный, и описывать сложные структуры данных на нем не в пример удобнее. Другое дело, что настолько сложные структуры, для которых недостаточно описания JSON, встречаются очень редко.
Она опубликована в трех хабах, один из них - это C++. Да, вы правильно заметили, здесь речь не об использовании C++, это рассказ о разработке. В общем-то, в введении я это подчеркнул, что код используется только для иллюстрации. Реализация могла быть и на другом языке, в рассматриваемо контексте это не принципиально. Здесь речь идет о технических решениях, а не об использовании языка в том или ином аспекте. Но, посольку реализация была на C++, то я посчитал нужным добавить статью и в этот хаб.
Почему С++. В первую очередь, из-за быстродействия. Java по этому критерию отпадает сразу - в этом аспекте она не может тягаться с C++. Go: по своей парадигме это больше процедурный язык, чем объектно-ориентированный, на нем проблематично реализовывать сложные модели. Rust: да, это конкурент C++, но в настоящее время C++ имееет бОльшую поддержку в плане различных библиотек. Например, вы знаете на расте аналог libsodium ? Может, и есть, но я не слышал. В этом плане C++ более знаком - его библиотеки у всех на слуху, тот же буст имеет практически все необходимое.
А что именно не понятно? Разложите общее непонимание на составляющие, выделите между ними связи, проанализируйте, как одно непонимание влияет на другое, и задавайте вопросы - все отвечу. Когда пробелы заполнятся, непонимание пройдет (мне так кажется).
Да, и забыл добавить. Internet - это означает Inter-net, т.е. "межсетевой протокол". То есть, это протокол для объединения сетей.
Это вопрос терминологии. Смотря что мы понимаем под интернетом. Если мы рассматриваем www, с его доменными именами, сайтами, и т.п. - они работают на базе IP. Но сам IP не является www. Можно организовать домашнюю локальную сеть, на базе IP, объединяющую бытовые устройства, - будет ли эта сеть интернетом? И да, и нет.
Service discovery не предназначен для маршрутизации и передачи информации. Его задача - предоставлять информацию о нахождении сервисов. Его, в принципе, можно использовать для передачи информации, но тогда у вас получается не одноранговая, а централизованная клиент-серверная система.
Узел 1 хочет отправить сообщение узлу 10. Он обращается к service discovery, и говорит, "дай мне адрес узла 10". Зачем тогда строить маршрут? Он может сразу отправить сообщение узлу 10. Единственное, ему необходимо иметь подключение к этому узлу. Как и ко всем остальным. Мы приходим к 1 случаю - полный граф, все соединены со всеми.
Если хотите использовать service discovery для коммуникации, тогда вам нужно его использовать как коммутационный сервер. Все сервисы подключены к единой точке, отправляют туда сообщения, а service сразу пересылает их получателю, поскольку знает его адрес. Широковещательная рассылка будет очень простой - разослать сообщение всем подключенным узлам. Но неэффективной - множество дубликатов сообщений будет идти по одним и тем же IP адресам в IP маршрутах. Тут уж все зависит от требований.
Для небольших сетей, порядка нескольких сотен, схема сработает, при условии, что service discovery будет достаточно мощный. Но с маштабированием будет не очень - с ростом количества узлов все упрется в пропускную способность центрального сервера.
IP - это не интернет-протокол. Это транспортный протокол, который доставляет пакеты от источника к получателю. Правила маршрутизации здесь задаются физическими устройствами - сетевыми коммутаторами. А уже интернет-протоколы, тот же HTTP, работает на базе IP адресов.
Оверлейная сеть также работает на базе IP адресов, т.е. это верхний уровень. Упрощенно, IP адреса можно рассматривать как физический уровень, а идентификаторы - как логический. Т.е., сеть, объединяющая узлы с идентификаторами, представляет собой некоторое подмножество IP сети.
Не, WebAssembly здесь не поможет. Все проблемы, связанные с верификацией исходного и двоичного кода, остаются те же самые
Скажем так. XML гораздо более выразительный, и описывать сложные структуры данных на нем не в пример удобнее. Другое дело, что настолько сложные структуры, для которых недостаточно описания JSON, встречаются очень редко.
Она опубликована в трех хабах, один из них - это C++. Да, вы правильно заметили, здесь речь не об использовании C++, это рассказ о разработке. В общем-то, в введении я это подчеркнул, что код используется только для иллюстрации. Реализация могла быть и на другом языке, в рассматриваемо контексте это не принципиально. Здесь речь идет о технических решениях, а не об использовании языка в том или ином аспекте. Но, посольку реализация была на C++, то я посчитал нужным добавить статью и в этот хаб.
Почему С++. В первую очередь, из-за быстродействия. Java по этому критерию отпадает сразу - в этом аспекте она не может тягаться с C++. Go: по своей парадигме это больше процедурный язык, чем объектно-ориентированный, на нем проблематично реализовывать сложные модели. Rust: да, это конкурент C++, но в настоящее время C++ имееет бОльшую поддержку в плане различных библиотек. Например, вы знаете на расте аналог libsodium ? Может, и есть, но я не слышал. В этом плане C++ более знаком - его библиотеки у всех на слуху, тот же буст имеет практически все необходимое.
Как-то так.
Да, ошибочка вышла. Подкорректирую
А вы работали один? Это ведь экстремально сложно, работать в одиночку, и нести ответственность за все. И эмоционально очень тяжело.
А что именно не понятно? Разложите общее непонимание на составляющие, выделите между ними связи, проанализируйте, как одно непонимание влияет на другое, и задавайте вопросы - все отвечу. Когда пробелы заполнятся, непонимание пройдет (мне так кажется).