Насчёт памяти согласен. Это одна из больных проблем Ява-машины. Как и долгий старт. Ну а что вы хотите? Делать супернакрученную логику по загрузке классов и при этом не потерять в производительности?
Я нарочно здесь пел хвалебные песни. Но я ведь отметил, что недостатков хватает. О них расскажут другие.
На мой взгляд, в современных реалиях Ява может найти применение именно в виде легковесных лямбд, целиком грузить процессы слишком накладно. Причём для легких функций больше подойдут именно EJB, Spring в данном случае проигрывает как монолит и его уже вытесняют Quarcus и аналоги.
Хорошо, теперь всё встало на свои места. Реальное устройство, если вам верить, более плоское и простое, чем я себе представлял. В принципе, простота иногда выливается в надёжность.
Если все операторы получают адреса на одном уровне (что по-моему всё-таки не всегда верно), то иерархия существует только в структуре реестров, т.е. сугубо бюрократически обслуживается. Тогда да, действительно, нет прямой связи между диапазонами адресов и физическими подключениями.
Про корневые это я оговорился. Имелись в виду сертификаты самого верхнего уровня, привязанные к реальным диапазонам. Но сути это не меняет. Большая часть верхнеуровневых диапазонов, я подозреваю, в собственности крупнейших провайдеров. И тут дело десятое, кем они были выданы — одним ЛИРом или десятью с пяти континентов. Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков.
И если у одного телекома-ТНК 20% адресов интернета и монопольное право выдавать подписи своим приватным ключом на различные куски этого пространства, то на мой взгляд, очевидно, что "никакой, даже самый большой, оператор не может никак" — не совсем верно.
Спасибо за разъяснение по поводу цели подписи. Получается, что подписывается только голова (последний, или первый слева элемент) AS-PATH. Это действительно тогда защищает от анонса от чужого имени, не ломая маршруты. Но это решает лишь часть проблем с мошенничеством — а именно ддос атаки.
Атаки типа перехвата трафика, прослушки и чёрной дыры всё равно возможны, так как все остальные элементы AS-PATH, его хвост, по-прежнему могут быть произвольными. И если эндпойнт способен принять этот трафик, то он может сделать такой анонс. В крайнем случае, если сам не переварит, завалит трафиком партнёров. Если ещё при этом по-хитрому распределить среди них нагрузку, то и черная дыра остаётся актуальной.
Но тут, видимо нет универсального решения. Либо ограничение трафика, либо безопасность.
Выясняется — ресурсы BootJar запакованные не из библиотек (webjars), а из проекта, не включаются в перечисление, и это, оказывается, по дизайну! Подробности здесь.
Так в том и проблема, что туда при обычной сборке всё складывается. Ах да, я же не написал про это. Ну щас дополню: поскольку архив не war, то ресурсы таким war-способом не грузятся. Если бы амазон не накосячил, то без проблем бы из корня читалось.
Да, действительно, я не продвинутый специалист именно в этой области, хотя некоторый опыт и знания имеются.
Давайте на какой-нибудь конкретной модели разберём, что я имел в виду. На абстрактных понятиях, да ещё без полной уверенности в правильном их понимании трудно объясняться.
Итак, обычная, на мой взгляд, иерархическая схема подключения Интернет-провайдеров к сети. Стрелки с треугольниками — основное подключение с выделением адресов (и соответственно подписей к ним в RPKI). Стрелка галочкой — пиринг.
В этой модели я предполагаю, что провайдеры, подключенные к точке обмена, приходят туда с такой картиной мира, такими цепочками связности и объявляют их.
То есть провайдер P2.2 объявляет маршрут вплоть до P1.1.1 или обобщённо до P1.1 или даже IPS1 как последовательность P2.2 -> ISP2 -> P1.2 -> IPS1 (-> P1.1 -> P1.1.1). По идее, он может это сделать, так как есть физический коннект ISP2 -> P1.2 между сетями 1-го и 2-го регионального провайдера, и о нём известно P2.2.
Точно так же анонсируются цепочка P4.2.1 -> P4.2
Мне бы прояснить, могут ли участники пира объявить в новых условиях пути до подсетей, сокращающих сетевые расстояния, которые к ним прямого отношения не имеют (P1.2, P1.1 и P1.1.1 для P2.2)? Если нет, то это вроде бы значит, что пиринг запрещён/сломан.
Теперь, что касается коммерческих и бюрократических инстанций. Да, подписи анонсов выдаются RIR/NIR или аффилированными структурами. Но получают их в своей массе всё равно те же владельцы адресов, коммерческие сети и в тех же объёмах, в каких у этих сетей есть номерная ёмкость. А значит глобальные игроки получают корневые сертификаты даже не одного региона, а сразу нескольких и могут теоретически распоряжаться ими как угодно.
То есть фактическими распорядителями маршрутов становятся только глобальные телекомы (содержатели физических каналов) и им лояльные суб-провайдеры. В этом моё опасение.
Я не вижу здесь каких то сложностей. Если произошло исключение, мы его фиксируем, получаем на него ссылку, затем возбуждаем исключение в нативе, вылетаем на уровень JNI и заново бросаем ява-исключение с сохраненным исключением в качестве причины
Поток выполнения (control flow) — стандартное понятие. В нашем случае он происходит на 2-х уровнях: на верхнем уровне байткода и нижнем нативном. При переходе из одного в другой приходиться все данные преобразовывать из одного представления в другое, это я и называю конвертированием.
«при привязке их к нативу» — имеется в виду использование ява-объекта с нативными методами. В моем случае реализация этих методов находится в соответствующих плюсовых объектах. То есть ява-объекты считаются привязанными к нативу, если им в соответствие есть нативная функия. Всё просто.
Пример:
class Foo extends NativeObject{
native void exec();
native int calc();
}
class Foo: public NativeObject{
void exec();
int calc();
}
Эта привязка называется прямым вызовом (на developerworks, т.к. jvm непосредственно зовет эти методы с передачей им аргументов). Обратный вызов — из натива в jvm — производится через явовские коллбэки. Подробнее можно прочитать здесь
Указатель на нативный объект достается в функциях Java_Foo_*одним коллбэком. Это пока что одно из неэффективных решений. По хорошему этот указатель можно сразу передавать в качестве параметра, но я не хотел захламлять интерфейсы в яве.
А что конкретно интересует? Обработка исключений в ява машине стандартна: после вызова каждого метода JNI environment делаем checkException() и по желанию describeException(). Это всё подробно описано в JNI specification.
Здесь я только акцентировал внимание на способе удобной обёртки ява ошибок в плюсовые и обратно, поскольку частенько приходится менять контекст выполнения с байткода в натив и обратно.
Если очень хочется, можно портировать, кто бы только взялся?
Если у исходников нормальная система сборки, желательно make — она лучше всего согласуется с *.mk, то построить её под Android, думаю не составит особого труда. 4 аналогичных примера уже есть в составе NDK
Насколько я заметил, эта библиотека и под обычными системами ещё толком не работает. Есть ли смысл еёпортировать на Андроид? Там у них более приоритетные версии есть. Хотя при желании конечно запортировать можно все, что угодно. Чем собственно сейчас и занимаюсь.
Я нарочно здесь пел хвалебные песни. Но я ведь отметил, что недостатков хватает. О них расскажут другие.
На мой взгляд, в современных реалиях Ява может найти применение именно в виде легковесных лямбд, целиком грузить процессы слишком накладно. Причём для легких функций больше подойдут именно EJB, Spring в данном случае проигрывает как монолит и его уже вытесняют Quarcus и аналоги.
Хорошо, теперь всё встало на свои места. Реальное устройство, если вам верить, более плоское и простое, чем я себе представлял. В принципе, простота иногда выливается в надёжность.
Если все операторы получают адреса на одном уровне (что по-моему всё-таки не всегда верно), то иерархия существует только в структуре реестров, т.е. сугубо бюрократически обслуживается. Тогда да, действительно, нет прямой связи между диапазонами адресов и физическими подключениями.
Про корневые это я оговорился. Имелись в виду сертификаты самого верхнего уровня, привязанные к реальным диапазонам. Но сути это не меняет. Большая часть верхнеуровневых диапазонов, я подозреваю, в собственности крупнейших провайдеров. И тут дело десятое, кем они были выданы — одним ЛИРом или десятью с пяти континентов. Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков.
И если у одного телекома-ТНК 20% адресов интернета и монопольное право выдавать подписи своим приватным ключом на различные куски этого пространства, то на мой взгляд, очевидно, что "никакой, даже самый большой, оператор не может никак" — не совсем верно.
Спасибо за разъяснение по поводу цели подписи. Получается, что подписывается только голова (последний, или первый слева элемент) AS-PATH. Это действительно тогда защищает от анонса от чужого имени, не ломая маршруты. Но это решает лишь часть проблем с мошенничеством — а именно ддос атаки.
Атаки типа перехвата трафика, прослушки и чёрной дыры всё равно возможны, так как все остальные элементы AS-PATH, его хвост, по-прежнему могут быть произвольными. И если эндпойнт способен принять этот трафик, то он может сделать такой анонс. В крайнем случае, если сам не переварит, завалит трафиком партнёров. Если ещё при этом по-хитрому распределить среди них нагрузку, то и черная дыра остаётся актуальной.
Но тут, видимо нет универсального решения. Либо ограничение трафика, либо безопасность.
Правильно — двухсот (двух нот)
Делегирование от РИРов на первой схеме, конечно отличается от провайдерского.
Да, действительно, я не продвинутый специалист именно в этой области, хотя некоторый опыт и знания имеются.
![image](https://habrastorage.org/r/w1560/getpro/habr/comment_images/abe/7c8/cab/abe7c8cabe86f22638a7e7b22fba64c8.png)
Давайте на какой-нибудь конкретной модели разберём, что я имел в виду. На абстрактных понятиях, да ещё без полной уверенности в правильном их понимании трудно объясняться.
Итак, обычная, на мой взгляд, иерархическая схема подключения Интернет-провайдеров к сети. Стрелки с треугольниками — основное подключение с выделением адресов (и соответственно подписей к ним в RPKI). Стрелка галочкой — пиринг.
В этой модели я предполагаю, что провайдеры, подключенные к точке обмена, приходят туда с такой картиной мира, такими цепочками связности и объявляют их.
![image](https://habrastorage.org/r/w1560/getpro/habr/comment_images/0b9/0e1/cd7/0b90e1cd7fbec17a02701cc6fffc2d79.png)
То есть провайдер P2.2 объявляет маршрут вплоть до P1.1.1 или обобщённо до P1.1 или даже IPS1 как последовательность P2.2 -> ISP2 -> P1.2 -> IPS1 (-> P1.1 -> P1.1.1). По идее, он может это сделать, так как есть физический коннект ISP2 -> P1.2 между сетями 1-го и 2-го регионального провайдера, и о нём известно P2.2.
Точно так же анонсируются цепочка P4.2.1 -> P4.2
Мне бы прояснить, могут ли участники пира объявить в новых условиях пути до подсетей, сокращающих сетевые расстояния, которые к ним прямого отношения не имеют (P1.2, P1.1 и P1.1.1 для P2.2)? Если нет, то это вроде бы значит, что пиринг запрещён/сломан.
Теперь, что касается коммерческих и бюрократических инстанций. Да, подписи анонсов выдаются RIR/NIR или аффилированными структурами. Но получают их в своей массе всё равно те же владельцы адресов, коммерческие сети и в тех же объёмах, в каких у этих сетей есть номерная ёмкость. А значит глобальные игроки получают корневые сертификаты даже не одного региона, а сразу нескольких и могут теоретически распоряжаться ими как угодно.
То есть фактическими распорядителями маршрутов становятся только глобальные телекомы (содержатели физических каналов) и им лояльные суб-провайдеры. В этом моё опасение.
«при привязке их к нативу» — имеется в виду использование ява-объекта с нативными методами. В моем случае реализация этих методов находится в соответствующих плюсовых объектах. То есть ява-объекты считаются привязанными к нативу, если им в соответствие есть нативная функия. Всё просто.
Пример:
Привязывается на функции
А они в свою очередь обращаются к методам
Эта привязка называется прямым вызовом (на developerworks, т.к. jvm непосредственно зовет эти методы с передачей им аргументов). Обратный вызов — из натива в jvm — производится через явовские коллбэки. Подробнее можно прочитать здесь
Указатель на нативный объект достается в функциях Java_Foo_*одним коллбэком. Это пока что одно из неэффективных решений. По хорошему этот указатель можно сразу передавать в качестве параметра, но я не хотел захламлять интерфейсы в яве.
Здесь я только акцентировал внимание на способе удобной обёртки ява ошибок в плюсовые и обратно, поскольку частенько приходится менять контекст выполнения с байткода в натив и обратно.
Если у исходников нормальная система сборки, желательно make — она лучше всего согласуется с *.mk, то построить её под Android, думаю не составит особого труда. 4 аналогичных примера уже есть в составе NDK