Как правильно сказать: "Добро пожаловать в облачные технологии"?! Наверное в современной терминологии Облаком называется граница знаний, куда вас не пустили, где технологии недоступные для вашего понимая, вам даже не рассказали что это.
Моя глобальная задача -- множество устройств, которые обладают коллективным разумом. Частная задача -- эффективное взаимодействие множества серверов в пределах видимости, в одной серверной и в одной локальной сети, в демилитаризованной зоне, где важно быстро и четко.
Концепция №1: Язык общения должен быть структурированный, потому что общение происходит через обмен объектами. Структурированных языков для описания данных очень не много, если разобраться, перечисляю: XML, ASN1 BER/DER, JSON. Я выбрал JSON, потому что модно и обработка выполняется быстрее XML. В следующий раз выберу BER, потому что компактно и потому что LDAP. Для отладки удобно использовать текстовый язык.
Концепция №2: Облачные сервисы строятся на технологии HTTP REST+OAuth2, в этой технологии не хватает операции рассылки уведомлений о событиях. Операцию рассылки уведомлений можно выполнить с использованием заголовков NOTIFY * HTTP/1.1 и пакетов UDP, только в стандарте такого заголовка нет. Есть расширения протокола HTTP, меня привлек протокол SSDP -- простой протокол обнаружения сервисов, он же UPnP. Протокол не стандартный, нет на него RFC. Уведомления, если не по подписке, то распространяются мультикастами. Например, для рассылки мультикастов SSDP используется адрес 239.255.255.250 порт 1900.
Концепция №3: Переходим на Zeroconfig. Делается это просто: надо освоить IPv6 и забыть про DNS. В технологии IPv6 есть понятие link-local адреса, пакеты будут распространятся в пределах локальной сети. IPv6 link-local multicast -- это адреса вида FF02::xxxx. Чтобы отладка была удобной использую Wireshark, который понимает три вещи из перечисленных: SSDP/UDP/IPv6, HTTP, JSON. Для того чтобы состыковать все три формата использую UDP/IPv6 адрес FF02::C порт 1900.
Концепция №4: Использование заголовков HTTP для управления версиями. При чтении исходного файла методом GET/HEAD используются два заголовка: Last-Modified - дата последнего изменения, и ETag - хеш и/или уникальный идентификатор версии. Для обновления файла на сервере методом PUT/POST/DELETE используется условие If-Unmodified-Since, которое позволяет обеспечить атомарность доступа к файлу. Проверить целостность можно заголовком If-Match. Обновить локальную копию файла следует, когда выполнены условия заголовков If-Modified-Since или If-None-Match в запросе. В новой версии стандарта HTTP/1.1 (редакция 2014г) исключили заголовок Content-Version, о нем стараюсь не думать, информацию о версии можно передавать в заголовке ETag.
Для кого эта статья? Ну уж точно не для тех, кто сидит на PHP или на JavaScript. Как нибудь стоит описать явным образом, каким заклятием можно забиндить демона на IPv6-multicast. Заклинаний и тайных знаний MSDN явно не достаточно для такой процедуры.
Тем кто близко знаком с MSDN рекомендую поизучать протокол WebDAV и httpu в изложении Microsoft. Букву 'u' добавляют, чтобы обозначить расширение HTTP поверх UDP. Протокол WebDAV в интерпретации Microsoft, помимо нестандартного метода NOTIFY, и блокирующих методов LOCK/UNLOCK, имеет еще несколько нестандартных методов, например SUBSCRIBE, который позволяет оформить подписку пользователя на ресурс с целью получения уведомлений NOTIFY по протоколу HTTP/UDP. Да, в RFC на WebDAV таких методов нет, но мне они очень бы пригодились для изготовления демонического сервиса.
Хотелось бы поделиться опытом, как писать кросс-платформенные сервисы на IPv6/IPv4 multicast. Скомпилировал одну и ту же программу на ARM GNU/Linux и MS/Mingw.
[RFC 4918] HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV), June 2007
[RFC 7232] HTTP/1.1 Conditional Requests, June 2014
[RFC 6762] Multicast DNS, February 2013
Моя глобальная задача -- множество устройств, которые обладают коллективным разумом. Частная задача -- эффективное взаимодействие множества серверов в пределах видимости, в одной серверной и в одной локальной сети, в демилитаризованной зоне, где важно быстро и четко.
Концепция №1: Язык общения должен быть структурированный, потому что общение происходит через обмен объектами. Структурированных языков для описания данных очень не много, если разобраться, перечисляю: XML, ASN1 BER/DER, JSON. Я выбрал JSON, потому что модно и обработка выполняется быстрее XML. В следующий раз выберу BER, потому что компактно и потому что LDAP. Для отладки удобно использовать текстовый язык.
Концепция №2: Облачные сервисы строятся на технологии HTTP REST+OAuth2, в этой технологии не хватает операции рассылки уведомлений о событиях. Операцию рассылки уведомлений можно выполнить с использованием заголовков NOTIFY * HTTP/1.1 и пакетов UDP, только в стандарте такого заголовка нет. Есть расширения протокола HTTP, меня привлек протокол SSDP -- простой протокол обнаружения сервисов, он же UPnP. Протокол не стандартный, нет на него RFC. Уведомления, если не по подписке, то распространяются мультикастами. Например, для рассылки мультикастов SSDP используется адрес 239.255.255.250 порт 1900.
Концепция №3: Переходим на Zeroconfig. Делается это просто: надо освоить IPv6 и забыть про DNS. В технологии IPv6 есть понятие link-local адреса, пакеты будут распространятся в пределах локальной сети. IPv6 link-local multicast -- это адреса вида FF02::xxxx. Чтобы отладка была удобной использую Wireshark, который понимает три вещи из перечисленных: SSDP/UDP/IPv6, HTTP, JSON. Для того чтобы состыковать все три формата использую UDP/IPv6 адрес FF02::C порт 1900.
Концепция №4: Использование заголовков HTTP для управления версиями. При чтении исходного файла методом GET/HEAD используются два заголовка: Last-Modified - дата последнего изменения, и ETag - хеш и/или уникальный идентификатор версии. Для обновления файла на сервере методом PUT/POST/DELETE используется условие If-Unmodified-Since, которое позволяет обеспечить атомарность доступа к файлу. Проверить целостность можно заголовком If-Match. Обновить локальную копию файла следует, когда выполнены условия заголовков If-Modified-Since или If-None-Match в запросе. В новой версии стандарта HTTP/1.1 (редакция 2014г) исключили заголовок Content-Version, о нем стараюсь не думать, информацию о версии можно передавать в заголовке ETag.
Для кого эта статья? Ну уж точно не для тех, кто сидит на PHP или на JavaScript. Как нибудь стоит описать явным образом, каким заклятием можно забиндить демона на IPv6-multicast. Заклинаний и тайных знаний MSDN явно не достаточно для такой процедуры.
Тем кто близко знаком с MSDN рекомендую поизучать протокол WebDAV и httpu в изложении Microsoft. Букву 'u' добавляют, чтобы обозначить расширение HTTP поверх UDP. Протокол WebDAV в интерпретации Microsoft, помимо нестандартного метода NOTIFY, и блокирующих методов LOCK/UNLOCK, имеет еще несколько нестандартных методов, например SUBSCRIBE, который позволяет оформить подписку пользователя на ресурс с целью получения уведомлений NOTIFY по протоколу HTTP/UDP. Да, в RFC на WebDAV таких методов нет, но мне они очень бы пригодились для изготовления демонического сервиса.
Хотелось бы поделиться опытом, как писать кросс-платформенные сервисы на IPv6/IPv4 multicast. Скомпилировал одну и ту же программу на ARM GNU/Linux и MS/Mingw.
[RFC 4918] HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV), June 2007
[RFC 7232] HTTP/1.1 Conditional Requests, June 2014
[RFC 6762] Multicast DNS, February 2013
Комментариев нет:
Отправить комментарий