Ваш подход описан в первой части. Честно говоря, в рабочей версии управление большими страницами я тоже сделал связным списком (данные на следующую страницу — в хидере страницы). Но, чтобы не перегружать статью, переписал на vector<>, на быстродействие это окажет минимальное влияние.
В статье описаны две совершенно разных подхода:
1. Блоки одинакового размера, с активным выделением-освобождением
2. Разношёрстные блоки с быстрым выделением, но освобождаются только все сразу (должны иметь одинаковое время жизни смерти)
Да, во втором случае, в пуле могуть быть разные объекты, но т.к. удаление запрещено, выделение памяти очень простое и разделение по пулам мне кажется, не даст ускорения (с чего бы...)
hole punching не поюзаешь для коммерческих решений. это же эксплуатация дыры, по сути.
проверял, оно работает далеко не везде: на ADSL-модеме ZyXEL работало, а на роутерах с RouterOS или FreeBSD (NAT силами ipfw) — увы. то есть, надёжный способ — релеи
кроме того, для координации hole punching нужен сторонний сервер, а он уже может ответить, что фокус не удался и трафик надо гнать через релей, даже когда роутеры клиентов позволили бы прямое соединение
судя по примерам, автор говорит о программах, меняющих свою логику под воздействием входных данных.
на любой интерпретатор можно посмотреть в двух точек зрения:
— он выполняет поступающие команды строго по порядку и ничего неожиданного в нём нет.
— при поступлении программы он начинает работать по логике программы, совершенно непредсказуемо на момент создания интерпретатора
кто переводит с русского на английский — интерпретатор или подаваемая на него программа? а если провести грань между ними сложно, как в вышеприведённой программе STUDENT?
да, и ещё проблема этого кода — создание CValue вне наследника CStructBase. тогда этот CValue допишется в последний созданный экземпляр CStructBase (который может быть уже разрушен).
по-хорошему, после завершения всех конструкторов членов CMyStruct надо сделать g_mapByThreadId[GetCurrentThreadId()] = NULL
что-то не соображу, как это сделать автоматически, чтобы не повторять в каждом конструкторе CMyStruct
с double будет плохо, потому что одно число в формате с плавающей точкой (мантисса-порядок) может имет разные двоичные предстваления. грубо, 3*10^6=30*10^5
но скорее глюков можно огрести на выравнивании. в структуре
struct MyClass {
char x;
int y;
};
между полями будет 3 байта для выравнивания, заполненных мусором.
их нужно исключить из сравнения.
вопрос в том, разрешено ли работнику выбирать себе пароль самостоятельно (т.е. менять его на своё усмотрение).
тыщу раз сталкивался: если первый пароль был mypassword, то при энфорсинге политики смены пароля работники ставят mypassword1, далее mypassword2 и т.д…
т.е. получить начальный пароль весьма интересно злоумышленнику
Зачем упускать прибыль. Вот стоит сотрудник в пробке, в очереди. По привычке глянул в почту, увидел проблему и мозг начал работать над её решением пользу компании, мозг ведь не выключишь. Пришёл на рабочее место с готовым решением и думает над следующей проблемой.
Минуточку, а причём здесь андроид? Если протокол требует знания пароля от клиента, то как ни шифруй его, всё равно где-то он появится в открытом виде. Другое дело, если бы EAS мог на основании пароля выдавать девайсу уникальный токен, а потом пароль больше не требовался и удалялся из памяти в любом виде. То, что в винде пароль зашифрован каким-нибудь примитивным XOR-ом (или AES256, не суть, при наличии ключа на том же девайсе) даёт ложное чувство защищённости
В случае кражи с целью доступа к данным в первую очередь злоумышленник извлечёт батарею, затем получит доступ к памяти без загрузки ОС (почти у каждой модели телефона есть режимы recovery, bootloader, или и то, и другое).
В случае кражи с целью продать девайс, злоумышленник в первую очередь сам сделает wipe.
То есть, функционал защищает только от случайных незадачливых воришек.
Любопытно, что блокировка девайса на сервере не предотвращает доступ к данным. Все реквизиты доступа, в том числе свой доменный пароль, я обнаружил в файле
/data/data/com.htc.android.mail/shared_prefs/EASSetupWizard.xml
Узнав пароль, злоумышленник может заходить на корпоративную почту через OWA, или настроив ящик на другом устройстве, не забаненном.
Андроид вообще в этом смысле не пытается делать security through obscurity. Например, пароли всех WiFi точек тоже лежат открыто.
В статье описаны две совершенно разных подхода:
1. Блоки одинакового размера, с активным выделением-освобождением
2. Разношёрстные блоки с быстрым выделением, но освобождаются только все сразу (должны иметь одинаковое время
жизнисмерти)проверял, оно работает далеко не везде: на ADSL-модеме ZyXEL работало, а на роутерах с RouterOS или FreeBSD (NAT силами ipfw) — увы. то есть, надёжный способ — релеи
кроме того, для координации hole punching нужен сторонний сервер, а он уже может ответить, что фокус не удался и трафик надо гнать через релей, даже когда роутеры клиентов позволили бы прямое соединение
на любой интерпретатор можно посмотреть в двух точек зрения:
— он выполняет поступающие команды строго по порядку и ничего неожиданного в нём нет.
— при поступлении программы он начинает работать по логике программы, совершенно непредсказуемо на момент создания интерпретатора
кто переводит с русского на английский — интерпретатор или подаваемая на него программа? а если провести грань между ними сложно, как в вышеприведённой программе STUDENT?
парадокс описан ещё Джоном Сёрлем
наверное, я дурак ))
по-хорошему, после завершения всех конструкторов членов CMyStruct надо сделать g_mapByThreadId[GetCurrentThreadId()] = NULL
что-то не соображу, как это сделать автоматически, чтобы не повторять в каждом конструкторе CMyStruct
в с++
__declspec(thread) CStructBase* currentClass;
в C#, Pascal и т.п. тоже есть аналогичные windows-specific кейворды ([ThreadStatic], threadvar)
но скорее глюков можно огрести на выравнивании. в структуре
между полями будет 3 байта для выравнивания, заполненных мусором.
их нужно исключить из сравнения.
тыщу раз сталкивался: если первый пароль был mypassword, то при энфорсинге политики смены пароля работники ставят mypassword1, далее mypassword2 и т.д…
т.е. получить начальный пароль весьма интересно злоумышленнику
никого не напрягает.
если же это необходимо для самописной ORM, или XML-сериализатора, то почему бы и нет
Зачем упускать прибыль. Вот стоит сотрудник в пробке, в очереди. По привычке глянул в почту, увидел проблему и мозг начал работать над её решением пользу компании, мозг ведь не выключишь. Пришёл на рабочее место с готовым решением и думает над следующей проблемой.
В тему:
habrahabr.ru/post/135236/
В случае кражи с целью доступа к данным в первую очередь злоумышленник извлечёт батарею, затем получит доступ к памяти без загрузки ОС (почти у каждой модели телефона есть режимы recovery, bootloader, или и то, и другое).
В случае кражи с целью продать девайс, злоумышленник в первую очередь сам сделает wipe.
То есть, функционал защищает только от случайных незадачливых воришек.
Любопытно, что блокировка девайса на сервере не предотвращает доступ к данным. Все реквизиты доступа, в том числе свой доменный пароль, я обнаружил в файле
/data/data/com.htc.android.mail/shared_prefs/EASSetupWizard.xml
Узнав пароль, злоумышленник может заходить на корпоративную почту через OWA, или настроив ящик на другом устройстве, не забаненном.
Андроид вообще в этом смысле не пытается делать security through obscurity. Например, пароли всех WiFi точек тоже лежат открыто.
Тогда populate_statdata и VcfInitializer будут не нужны