Почти идеальный виртуальный CDN

Почему почти? Нет в мире совершенства, всегда хочется еще чего-то или забываешь о чем-то.

Виртуальный - потому что нет его как такового только незримое улучшение каких-то характеристик.

Вот несколько неплохих характеристик виртуального CDN:

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

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

Фасеточные фонари

Идея навеяна системой используемой в машинах выше среднего класса когда отражатель вместе с фарой поворачивается чтобы осветить нужные участки дороги и сдвигать луч чтобы не слепить встречные авто или немного сдвигать луч при повороте.

Этого же можно добиться заменив в стандартных фарах лампочки или другой излучающий элемент такую конструкцию:

1. на излучатель виде фасеточного глаза насекомых, содержащего несколько светодиодов с собственными линзами с отдельным управлением каждым светоизлучающим элементом, что позволит освещать только участки и чем на больше количество зон разбиты такие излучатели тем точнее можно регулировать освещённость. Обратную часть излучателя можно сделать не управляемым или просто обеспечивающим не сфокусированный ближний свет, так как они будут использоваться через отражатель плюс линзы на передней части. Но также нужно учитывать ограничение стандартное оптики фары когда невозможно регулировать полное направление света из-за использования дополнительных линзовых элементов на стекле фары заднего отражателя. Задний отражатель используемый в фарах можно не брать во внимание так как отбивает только обратный свет;
2. две инфракрасные камеры(по возможности);
3. одну обычную.

Принцип работы:
излучатель инфракрасного диапазона с двумя камерами используется как объёмный дальномер (по отличию данных изображения в стерео кадрах можно определить примерное расстояние до объектов), чтобы просканировать площадь перед автомобилем и используя дополнительно данные с обычной камеры как датчика освещённости меняя область засвеченную в фарами и яркость в этих областях чтобы создать равномерную освещённость перед автомобилем.

Использование не полного комплекта:

• Можно использовать обычную камеру плюс фасеточные излучатели без объёмного датчика для получения примерно равномерного освещения. Объёмный датчик только дает возможность регулировать освещённость для удаленных объектов с повышением их освещённости и минимальную освещённость как ближний свет для прилежащих, также эти датчики можно использовать для того чтобы снизить скорость перед препятствием.
• Без обычной камеры мы не можем определить общую освещённость и как следствие учесть другое внешнее освещение.

Основное достоинство такой системы отсутствие двигающихся частей и не нужны датчики положения.

Память

Управление памятью всегда является компромиссом между выделением памяти под все объекты с минимизацией изменения в виде cow принципа, что позволяет максимальное не блокируемое взаимодействие потоков с общей памятью и минимизацией утечек памяти. COW подход используется в языках с передачей сообщений и очень легковесными потоками - что позволит получить высокую производительность. Но память не освобождается в таких случаях до полного завершения всех процессов, потенциально имеющих возможность обратится к этой памяти, и нет возможности произвести утряску памяти без остановки всех процессов.

Для минимизации случаев, когда память уже не используется, но она освобождалась не в том порядке как выделялась, что часто бывает, так как память под результат выделяется в конце выполнения подпрограммы. Идея в том чтобы перед выполнением запомнить состояние выделения память или передать в функцию, перед окончанием выполнения, указатели на выделенные в ходе исполнения данные и переместить результат как можно ближе к предыдущей границе выделения памяти как было перед запуском под программы. Это позволяет более экономно использовать память, как пример с минимальными изменениями текущей логики выделения вызвать realloc для результата после освобождения всех ненужных объектов из памяти, что бы она пыталась переместить данные ближе к предыдущей границе (возможно, это потребует изменить внутреннюю семантику функции, так как возможно если памяти достаточно функции реального перемещения не выполняет), также это поможет, если использовалось динамическое увеличение буфера для работы при котором всегда при нехватке памяти выделялось в два раза больше, чем нужно для работы. Такая простая утряска решит проблему когда из-за большого количества повторных выделений и перемещений у нас память занята меленькими не занятыми областями, а результат далеко расположен по сравнению с изначальным выделением.

p2p over http

Идея проброса трафика через обычно открытый порт

Проброс point2point соединения через http соединение в теории можно осуществить через http 1.0 - так он позволяет иметь постоянное соединение, если не указывать размер результата. В таком случае соединение не будет закрыто до момента закрытия с обеих сторон, что позволяет после передачи стандартных минимальных заголовков иметь прямой канал.

Через прокси таким образом работать не получится так как буде работать только канал от сервера к клиенту, в обратную строну соединение не будет работать, можно создать прямое соединение через POST для отправки данных на сервер без указания размера данных используя передачу параметров запроса после заголовков не указывая multipart параметров и обратное через GET без указания размера. Такой способ соответствует спецификации в теории, но имеет несколько недостатков, так как мы имеем 2 соединения которые нужно объединить в одно виртуальное и обычно сервера не позволяют такое вольное отношение с протоколом вычитывая полностью данные с параметров запроса и буферизируя передаваемые данные и как результат такая система может работать не стабильно.

Как результат можно использовать POST запрос с указанием в ответе HTTP 1.0 без указания размера контента с обоих сторон без ожидание получения полного ответа с обоих сторон - в теории это должно повысить вероятность прохода трафика без задержек через прозрачные прокси и firewall - так как оно будет работать по протоколу который соответствует минимальном требованиям к обычно открытому порту для http.

Можно конечно использовать https - он будет более надежен в данном случае, так как после установления шифрованного соединения узлы через которые проходит трафик не имея ключа не могут влиять на трафик - но даже в этом случае нужно менять логику работы сервера и клиента - так как обычно они не рассчитаны на такое использование, когда после установления соединения мы передаем данные по другому протоколу.

Как расширение данного соединения можно сразу использовать потоковое сжатие подобное lzw в котором можно использовать дублирование символа сброса словаря, как признак того что нужно сбросить буферы и передать распакованный пакет дальше. На передающей стороне передавать такую последовательность в случае заполнения буфера передачи или срабатывание таймера на максимальную задержку на передачу пакета.

Android + autoconfig?

Android по размерам исходного кода более похож на дистрибутивы общего назначения, где есть несколько тысяч пакетов со сложными взаимосвязями. Последний Android содержит примерно 370 пакетов в терминах обычных дистрибутивов. Основное отличием от остальных дистрибутивов является использование жестко прописанные зависимостей, что обычно характерно для встраиваемых систем или внутренних продуктов заточенных на выполнение только жестко ограниченной функциональности без повторного использования другими продуктами.

Для Android - причина таких особенностей связана с тем что:

• нужно всегда иметь вне зависимости от окружения сборки получать одинаковый результат;
• собирается он с жесткой привязкой к одной аппаратуре, собирается только раз и после первоначальной продажи продукта обновления выпускаются только исправления безопасности, поэтому особой универсальности не требуется
• каждый производитель использует свои наработки по работе с аппаратурой, поэтому перенос с одной платформы на другую или обновление прошивки не требуется так как часто люди скорее купят новый телефон с новый пользовательским окружением чем будут обновлять прошивку так как после нее поменяется принцип пользовательского окружение, а люди не любят менять привычки - и новое устройство с новым пользовательским окружением предпочтительно
• большинство компонент непосредственно конечными пользователям не видно - так как пакетного менеджера нет и поставить что то по зависимостям нельзя и нужно предусмотреть максимально широкое API чтобы не тянуть все те же компоненты с пользовательских программами,
• встроенных программ тоже не много в отличии от других дистрибутивов - вкусы всех не предугадаешь и так можно оставить больше возможностей для внесения разнообразия сборщиками под продукт

Как следствие отсутствие классической инкрементальной сборки, отсутствие средств автоконфигурирования, жесткая привязка к кросскомриляции с изначально заданными параметрами, в общем не LFS или Gentoo.

Возможно это все можно решить, если изначально собирать все по принципам LFS и в эмуляторе конечной платформы. Но результат такой системы будет полностью переписанная сборка частей общих и характерных для остальных дистрибутивов Linux и опять таки сложная система с жесткими связями для пользовательского интерфейса где используется Dalvik, плюс проблема с драйверами к аппаратуре - так как Android позволяет больший разброс в идеях как работать с аппаратурой чем обычный linux и содержит части из других операционных систем, например binder (часть как следствие вечно живой Beos).