Интересно. Давайте копнем детальнее. Конкретный пример – это hetzner, который отдает на машины один /64. Проблема – сделать IPv6 внутри KVM-виртуалок на этой машине.
Допустим на хосте у нас есть конкретный IPv6 адрес: 2a01:fad:120:6f3a::2/64, и мы хотим заиметь виртуалку с адресом 2a01:fad:120:6f3a::10. У меня возникает следующая проблема:
Шлем «из мира» пакет на 2a01:fad:120:6f3a::10.
Пакет падает на маршрутизатор хецнера, который начинает у всех спрашивать, а не видел ли кто тут 2a01:fad:120:6f3a::10? (эти пакеты видно на внешнем интерфейсе хоста).
Поскольку хост непосредственно про этот адрес ничего не знает, то он ND успешно игнорирует, роутер шлет пакет назад – не, нету тут такого.
proxy_ndp «лечит» эту ситуацию тем, что хост среди ND запросов начинает обращать внимание на запросы с IP 2a01:fad:120:6f3a::10 (отвечая – шли сюда). Когда конкретный пакет падает на интерфейс правила маршрутизации позволяют перекинуть его с eth0 на vnet0 к гостю и все работает.
Минусы – надо поштучно добавлять все нужные IPv6 адреса в proxy_ndp.
Не совсем понял пример с тем, как можно избежать бриджа.
Допустим у нас /64 на внешнем интерфейсе машины А, и link-local на внутреннем, к которому подцеплена машина Б. В принципе, машина Б может использовать link-local адрес машины А с внутреннего интерфейса, но назад то как? Внешний маршрутизатор по ND будет искать машину Б, машина А об этом не в курсе, ND-пакеты не маршрутизируются, никто никого не видит.
Собственно, почему и возникает необходимось в линухах делать proxy_ndp.
По личному опыту. Беспошлинный ввоз в Ирландию что-то около 25 евро. Сверху этого – таможенная пошлина + VAT (собственно, как и везде). Впрочем, есть какие-то хитрые расчеты, по которым если сумма пошлины меньше определенной – то платить ее не надо. На практике – раз на раз не приходится, могут стребовать пошлину за посылку стоимостью 70 евро, а могут и задекларированную на 300 пропустить.
Но вот что удобно – таможня принимает документы только в электронном виде. Из документов – оригинальный инвойс. При этом оплата уже курьеру, никуда за посылкой ездить не надо.
И небольшой бонус сверху, у некоторых компаний офис в EU, и покупая посылку, которая физически едет из США растамаживать ее не надо, т.к. она считается проданной европейской компанией и VAT за нее уже уплачен.
Я сейчас строю сенсорные сети на базе ATmega и 802.15.4. На входе относительно дешевое железо, которое реально паять руками (ATmega для сети и сенсоров, MRF24J40MA для радио), на выходе UDP по IPv6 (через 6LoWPAN), которое можно зафорвардить даже на statsd элементарным образом.
К батареям относится экономно, потенциально может роутится мешем. «Базовая станция» – beaglebone с тем же mrf24j40ma, можно взять и RPi. Посматриваю на совмещенные варианты радио+mcu, но выходит не сильно дешевле и эффективнее, разве что по габаритам выигрыш.
У меня аналогичная сборка. Только вот мой dht22 как-то не очень надежен в показаниях температуры: у меня их два, один с dx.com, второй с adafruit, разница между их показаниями – до 5 градусов. bmp085 показывает температуру, схожую с одним из них ±2º, ему веры больше как-то.
Вики говорит, что в QR-код помещается чуть менее 3Kb. В принципе, AVR-ки впролне можно натаскивать на простые задачи впихивая все и в 2Kb, так что у этой задачи есть потенциальный практический успех (что сложно сказать о практическом применении, но это все же отличный just for fun).
Добавить сюда хорошую компрессию (мы же это выполняем на шустром современном железе) – и можно выручить еще немного места.
Остается вопрос – что будут делать эти приложения? Так или иначе, нужны примитивные арифметические операции, циклы. Это можно не придумывать заново, а взять один из наборов инструкций, которые хорошо себя чувствуют в тесном окружении. ARM Thumb сразу приходит в голову, потому что его можно было бы выполнять сразу на железе, но на самом деле этот набор было бы полезно расширить какими-то высокоуровневыми «прикладными» инструкциями (т.е. построить CISC архитектуру, в противовес RISC).
Успехов в общем, и обязательно отпишитесь по результатам, даже если ничего не выгорит (особенно если ничего не выгорит – будет интересно узнать о том, что вы перепробовали).
Я бы посоветовал начать непосредственно с битовых инструкций. Можно очень много сэкономить на месте, если не мерять все октетами (а вам то этого и не надо). Проблему необходимых «отступов» для тех же строк можно решить разными секциями (как это делается в бинарных файлах).
Пока в MTV – поговорите там в гугле на тему ООП и языков, которые применяются в продкашене. Много интересного можно узнать и про С++, который «умирает», и про «перформанс» Java.
Допустим на хосте у нас есть конкретный IPv6 адрес: 2a01:fad:120:6f3a::2/64, и мы хотим заиметь виртуалку с адресом 2a01:fad:120:6f3a::10. У меня возникает следующая проблема:
Шлем «из мира» пакет на 2a01:fad:120:6f3a::10.
Пакет падает на маршрутизатор хецнера, который начинает у всех спрашивать, а не видел ли кто тут 2a01:fad:120:6f3a::10? (эти пакеты видно на внешнем интерфейсе хоста).
Поскольку хост непосредственно про этот адрес ничего не знает, то он ND успешно игнорирует, роутер шлет пакет назад – не, нету тут такого.
proxy_ndp «лечит» эту ситуацию тем, что хост среди ND запросов начинает обращать внимание на запросы с IP 2a01:fad:120:6f3a::10 (отвечая – шли сюда). Когда конкретный пакет падает на интерфейс правила маршрутизации позволяют перекинуть его с eth0 на vnet0 к гостю и все работает.
Минусы – надо поштучно добавлять все нужные IPv6 адреса в proxy_ndp.
ЧЯДНТ?
Допустим у нас /64 на внешнем интерфейсе машины А, и link-local на внутреннем, к которому подцеплена машина Б. В принципе, машина Б может использовать link-local адрес машины А с внутреннего интерфейса, но назад то как? Внешний маршрутизатор по ND будет искать машину Б, машина А об этом не в курсе, ND-пакеты не маршрутизируются, никто никого не видит.
Собственно, почему и возникает необходимось в линухах делать proxy_ndp.
Для лучшей производительности рекомендуется тот канал, где меньше всего соседей ;-)
Но вот что удобно – таможня принимает документы только в электронном виде. Из документов – оригинальный инвойс. При этом оплата уже курьеру, никуда за посылкой ездить не надо.
И небольшой бонус сверху, у некоторых компаний офис в EU, и покупая посылку, которая физически едет из США растамаживать ее не надо, т.к. она считается проданной европейской компанией и VAT за нее уже уплачен.
К батареям относится экономно, потенциально может роутится мешем. «Базовая станция» – beaglebone с тем же mrf24j40ma, можно взять и RPi. Посматриваю на совмещенные варианты радио+mcu, но выходит не сильно дешевле и эффективнее, разве что по габаритам выигрыш.
PS: с homebrew так тоже работает, не считая некоторые косметические изменения.
И да, амазон обычно не занимается гарантийными случаями (не считая киндл, конечно), только в рамках полной поломки в первые месяц[ы] пользования.
Гитхаб же на днях запилил релизы: github.com/blog/1547-release-your-softwareEdit: да, это не сильно большой выход для больших бинарных ассетов
Добавить сюда хорошую компрессию (мы же это выполняем на шустром современном железе) – и можно выручить еще немного места.
Остается вопрос – что будут делать эти приложения? Так или иначе, нужны примитивные арифметические операции, циклы. Это можно не придумывать заново, а взять один из наборов инструкций, которые хорошо себя чувствуют в тесном окружении. ARM Thumb сразу приходит в голову, потому что его можно было бы выполнять сразу на железе, но на самом деле этот набор было бы полезно расширить какими-то высокоуровневыми «прикладными» инструкциями (т.е. построить CISC архитектуру, в противовес RISC).
Успехов в общем, и обязательно отпишитесь по результатам, даже если ничего не выгорит (особенно если ничего не выгорит – будет интересно узнать о том, что вы перепробовали).