Как работает Web Service Discovery?

Э-э... Это как? На стороне клиента держать базу соответствия (которая запросто может развалиться)? Или на стороне сервера принимать все запросы на один порт специальной службой, которая уже локально будет смотреть, какой порт нужен, и делать перенаправление? Или расширить спецификации DNS/DDNS/mDNS (что тоже будет работать не всегда)?

Ты не поверишь, такое уже есть, вот только в современных браузерах не работает. Соответствия лежат в /etc/services. Имена протоколов вместо номеров портов можно использовать в разных консольных утилитах. Например, вместо

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

iptables -A INPUT -p tcp --dport ssh -j ACCEPT

или так:

$ telnet microsoft.com http
Trying 134.170.185.46...
Connected to microsoft.com.
Escape character is '^]'.

А ещё в некотором софте есть поддержка SRV записей в DNS, там можно переопределить порты. Например, у xmpp порты не обязательно должны быть 5222/5269.

в некотором софте есть поддержка SRV записей в DNS

а файрфоксе есть?

о, бага!
https://bugzilla.mozilla.org/show_bug.cgi?id=14328

первое. Может и не развалиться.

Обязательно развалится для служб на динамически выбираемых и нестандартных портах. Следовательно - костыль.

поясни пожалуйста, что ты понимаешь под словом «развалится».

Я имею в виду такую схему:
на локальной машине крутится демон, который предоставляет API для регистрации и разрегистрации соответствий имя-порт (пусть он хранит свою базу в /etc/services, например)
приложения при парсинге URL обращаются к локально демону (могут через сокеты, могут через разделяемую память и любые другие механизмы межпроцессного взаимодействия) и получают номер порта, который используют

Что здесь по-твоему развалится?

То есть, предполагается, что каждая удалённая машина при запуске службы шарашит по сети мультикастом порт и имя службы? Так эта штука называется mDNS (а соответствующий демон в Linux - avahi-daemon). И ничего делать не надо - ну, разумеется, кроме ещё одной службы, которая будет принудительно анонсировать все запускаемые службы до тех пор, пока это не будет вбито в код самих прикладных служб, и переписывания клиентских приложений для поддержки записей SRV (насколько помню, они имеют одинаковую нотацию и в DNS, и в mDNS).

То есть, надо написать одну службу и переписать весь прикладной софт для поддержки mDNS/Avahi с учётом твоего пожелания. Ж;-)

предполагается, что каждая удалённая машина при запуске службы шарашит по сети мультикастом порт и имя службы?

нет, предполагается, что локальные сервисы сами регистрируются в локальном реестре.

mDNS/Avahi

мне надо посмотреть. Я знаю, что принтеры любят реализовывать/использовать mDNS не пока не представляю как это работает

Нет-нет-нет, погоди... Ну вот зарегистрировал ты локальный сервис локально. Где тот самый профит, которого ты ожидаешь при отсылке ссылки в виде «[имя узла]:[имя протокола]»? Как удалённый клиент тогда имя протокола будет разрешать? Обращаться сначала к локальной машине за этим?

Где тот самый профит, которого ты ожидаешь при отсылке ссылки в виде «[имя узла]:[имя протокола]»?

Профит в том, что мне не нужно знать адрес локального порта, а я могу записать его в обобщенном виде.

Я беру гиперссылку, которую я получил на своём узле p2p-сети, ничего в этой гиперссылке не меняю, отправляю получателю. А он на своём узле p2p-сети просто гиперссылку открывает, не заморачиваясь с тем, что у него узел сидит на другом порту.

Да почти так же, как обычный DNS. Только каждый узел держит свой список ресурсов, полученных мультикастом от других узлов. У меня это выглядит примерно так:

user@tower:~$ avahi-browse -avr
Версия сервера: avahi 0.6.31; Имя узла: tower.local
А Интр Прот Имя                                        Тип               Домен
+  wlan0 IPv4 Server                                        SFTP File Transfer   local
+  wlan0 IPv4 MacBook Pro - Administrator                   SFTP File Transfer   local
+  wlan0 IPv4 ____________ ____ Server                      Network File System  local
+  wlan0 IPv4 NFS public share on Server                    Network File System  local
+  wlan0 IPv4 ____________________ ____ Server              Network File System  local
+  wlan0 IPv4 ____________ ____ Server                      Network File System  local
+  wlan0 IPv4 __________ ____ Server                        Network File System  local
+  wlan0 IPv4 C0207AACE26513C9                              iPod Touch Music Library local
+  wlan0 IPv4 ____________ ____ Server                      iTunes Audio Access  local
+  wlan0 IPv4 ____________ ____ Server                      _rsp._tcp            local
+  wlan0 IPv4 ____________ ____ Server                      Web Site             local
+  wlan0 IPv4 Server                                        SSH Remote Terminal  local
+  wlan0 IPv4 MacBook Pro - Administrator                   SSH Remote Terminal  local
+  wlan0 IPv4 Server                                        Remote Disk Management local
+  wlan0 IPv4 tower                                         Remote Disk Management local
+  wlan0 IPv4 user@tower                              iChat Presence       local
+  wlan0 IPv4 Server [00:02:44:19:b2:f4]                    Workstation          local
+  wlan0 IPv4 tower [c0:4a:00:fc:72:a1]                     Workstation          local
=  wlan0 IPv4 Server                                        SFTP File Transfer   local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [22]
   txt = []
=  wlan0 IPv4 MacBook Pro - Administrator                   SFTP File Transfer   local
   hostname = [mac.local]
   address = [1.2.3.57]
   port = [22]
   txt = []
=  wlan0 IPv4 ____________ ____ Server                      Network File System  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [2049]
   txt = ["path=/media/Share/Видео"]
=  wlan0 IPv4 NFS public share on Server                    Network File System  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [2049]
   txt = ["path=/media/Share/Общая"]
=  wlan0 IPv4 ____________________ ____ Server              Network File System  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [2049]
   txt = ["path=/media/Share/Фотографии"]
=  wlan0 IPv4 ____________ ____ Server                      Network File System  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [2049]
   txt = ["path=/media/Share/Музыка"]
=  wlan0 IPv4 __________ ____ Server                        Network File System  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [2049]
   txt = ["path=/media/Share/Книги"]
=  wlan0 IPv4 C0207AACE26513C9                              iPod Touch Music Library local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [3689]
   txt = ["CtlN=Музыка на Server" "OSsi=0x1F5" "Ver=131073" "DvSv=2306" "DvTy=iTunes" "DbId=C0207AACE26513C9" "txtvers=1"]
=  wlan0 IPv4 ____________ ____ Server                      iTunes Audio Access  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [3689]
   txt = ["ffid=453a44d2" "Password=false" "Version=196610" "iTSh Version=131073" "mtd-version=21.0" "Machine Name=Музыка на Server" "Machine ID=2D1398D6" "Database ID=2D1398D6" "txtvers=1"]
=  wlan0 IPv4 ____________ ____ Server                      _rsp._tcp            local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [3689]
   txt = ["ffid=453a44d2" "Password=false" "Version=196610" "iTSh Version=131073" "mtd-version=21.0" "Machine Name=Музыка на Server" "Machine ID=2D1398D6" "Database ID=2D1398D6" "txtvers=1"]
=  wlan0 IPv4 Server                                        SSH Remote Terminal  local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [22]
   txt = []
=  wlan0 IPv4 MacBook Pro - Administrator                   SSH Remote Terminal  local
   hostname = [mac.local]
   address = [1.2.3.57]
   port = [22]
   txt = []
=  wlan0 IPv4 Server                                        Remote Disk Management local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [22]
   txt = []
=  wlan0 IPv4 tower                                         Remote Disk Management local
   hostname = [tower.local]
   address = [1.2.3.105]
   port = [22]
   txt = []
=  wlan0 IPv4 Server [00:02:44:19:b2:f4]                    Workstation          local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [9]
   txt = []
=  wlan0 IPv4 tower [c0:4a:00:fc:72:a1]                     Workstation          local
   hostname = [tower.local]
   address = [1.2.3.105]
   port = [9]
   txt = []
=  wlan0 IPv4 user@tower                              iChat Presence       local
   hostname = [tower.local]
   address = [1.2.3.105]
   port = [5298]
   txt = ["1st=Кирилл" "port.p2pj=5298" "last=Случанко" "status=avail" "ver=9lCQ5h7/WCRiOzEwFNec7Rx0w7o=" "txtvers=1" "nick=Кирилл Случанко" "phsh=b85b36411e3a27e036e182f493e71c5dbd31bb2a" "hash=sha-1" "node=http://telepathy.freedesktop.org/caps"]
=  wlan0 IPv4 ____________ ____ Server                      Web Site             local
   hostname = [Server.local]
   address = [1.2.3.1]
   port = [3689]
   txt = ["ffid=453a44d2" "Password=false" "Version=196610" "iTSh Version=131073" "mtd-version=21.0" "Machine Name=Музыка на Server" "Machine ID=2D1398D6" "Database ID=2D1398D6" "txtvers=1"]
: Кэш исчерпан
: Больше ничего на данный момент

Ещё раз. Ты получаешь на своём узле гиперссылку и отправляешь её получателю. Вопрос: Откуда получатель, у которого в ссылке написано «StrongDollarSuperServer:ssh» узнаёт, что у тебя SSH сидит на порту 2222, а не 22?

у получателя есть свой собственный комп CyrilSuperServer, на нём установлена нода p2p-сети (такая же как на моём сервере) и обращается он к своей ноде, а не к моей.

Для разных имён хостов есть обобщающее слово - localhost
а для разных номеров портов такого слова нет

Откуда получатель, у которого в ссылке написано «localhost:advanced-p2p-network» узнаёт, что у тебя узел advanced-p2p-network сидит на порту 2222, а не 22?

Получатель обратится к своему демону и он ему ответит какой у него локальный порт

как вариант, можно ещё подумать над написанием комплекта аддин-ов под все броузеры, которые будут заниматься URL-rewrite на стороне клиента.

Есть же https-everywhere.

Вот пусть переписывают URLы вида
advanced-p2p-network://rest/of/uri
в
http://localhost:advanced-p2p-network/rest/of/uri

Получатель обратится к своему демону и он ему ответит какой у него локальный порт

Внятность изложения мыслей в наше время - большая проблема. Попробуй ещё раз объяснить, пожалуйста - пока меня интересуют следующие моменты:

1. Зачем ты пересылаешь получателю ссылку? Ведь вряд ли для того, чтобы он по этой ссылке обратился к СВОЕЙ машине?

2. Тогда, если он обратится к ТВОЕЙ машине (или какой-то третьей) - откуда он возьмёт правильный порт на удалённой машине в случае, если он отличается от зарегистрированного у этого получателя локально? Ещё раз про пример с SSH - откуда он узнает, что для твоей машины «ssh» в ссылке нужно преобразовать в 2222, а не в 22, как у него записано локально?

Он предлагает сервис который слушает заранее определенный порт и отвечает на каких портах висят другие сервисы.

1. Зачем ты пересылаешь получателю ссылку?
Ведь вряд ли для того, чтобы он по этой ссылке обратился к СВОЕЙ машине?

Нет. Именно для того, чтобы он по этой ссылке обратился к своей машине. На его машине запущен его узел p2p-сети. Как узлы p2p-сети общаются между собой это уже другой разговор и их внутреннее дело.

То есть, узел p2p-сети является сервером и выполняется на машине пользователя (с именем localhost). Пользователь запускает броузер и обращается К СВОЕЙ МАШИНЕ, к локальному сервису по неизвестному порту.

2. Тогда, если он обратится к ТВОЕЙ машине (или какой-то третьей)

Пользователю не нужно обращаться к МОЕЙ машине. Я могу вообще находиться на другом континенте.

да-да-да. ВТОРОЙ сервис. первый - выдаёт контент p2p-сети, а второй висит на стандартном порту и сообщает нестандартный порт первого сервиса

1. Зачем ты пересылаешь получателю ссылку?

чтобы получатель ссылку открыл и прочитал контент.

Только процесс получения контента разделен на два этапа:
1) распространение контента между узлами
2) отображение контента своего узла в браузере

Ясно. Тогда ты предлагаешь не костыль, а МЕГАКОСТЫЛИЩЕ.

Особенно - при наличии mDNS/Avahi (хотя и без этого порт локальной службы определяется иногда просто легко, а иногда - достаточно легко). Ж;-)

порт локального сервера определяется иногда просто легко, а иногда - достаточно легко

Надо чтобы он не легко определялся, а автоматически

легко - это когда пользователь каждый урл меняет руками, я правильно понимаю?

Нет, неправильно. Связка «порт-процесс» определяется почти всегда - и для этого не нужен демон. Автоматически это делается в коде приложения - и это проще, чем писать в коде приложения обращение к демону за разрешением имени протокола или службы в порт и писать этот самый демон.

Но, повторюсь ещё раз - есть mDNS. Где всё из коробки и стандартизировано. Так что остаётся только соответствующим образом переписать клиентское приложение и прикладные службы. И это будет правильным решением.

И это будет правильным решением.

что тут правильное решение - это ещё большой вопрос.

Например, можно было бы придумать имя для протокола, написать обработчик протокола и он бы уже взаимодействовал с p2p-сетью как хочет (хоть сам пусть узлом является).

соответствующим образом переписать клиентское приложение

Про багу в файрфоксе, которую не могут закрыть 15 лет с 1999-го года я уже писал.

Например, можно было бы придумать имя для протокола, написать обработчик протокола и он бы уже взаимодействовал с p2p-сетью как хочет (хоть сам пусть узлом является)

Ну и? Зачем писать ещё что-то для его регистрации, если придуманное имя и занятый порт можно вполне отправить в mDNS?

Про багу в файрфоксе, которую не могут закрыть 15 лет с 1999-го года я уже писал.

И зачем на неё ссылаться? Точно так же, как не исправили багу - не будут принимать предложенный тобой костыль. И он не будет работать - следовательно, будет бесполезным.

И зачем на неё ссылаться?

mDNS - это только половина решения.

А зафиксить багу - это вторая половина решения

написать обработчик протокола

Ну и?

недостаточно мотивации

Да, половина. Которая уже есть. Так что остался самый минимум - о котором я и говорил вначале. Сделать так, чтобы приложения работали по этому стандарту. Ж;-) Это единственное, что придётся делать при любом варианте решения задачи.