использовал в некоторых проектах, но ИМХО данный компонент перегружен функциями, и нет нормального туториала как эти функции почикать, чтобы оставить только то что нужно.
И его значительно дольше кастомайзить, чем например qqFileUploader.
далеко не последние версии gcc упорно варнингами сыплют, что printf без формата вывода вызывается.
со второй проблемой уже все наелись, во многих книжках и статьях атака %n детально расписана.
ИМХО, если человек бездумно пишет код на плюсах, он и до использования printf забажет все нафиг.
не то чтобы прям в планах, но есть такая тенденция, которая мне не нравится:
давайте напишем сайт на php, прикрутим nginx, php-fpm, eaccelator, hip-hop, memcache и т.д. и т.п.
я конечно люблю пых, но есть очень прикольная серия статей www.insight-it.ru/highload/ один из смыслов которой «мы использовали пых, потому что так сложились обстоятельства».
1) там такая штука большая и ИМХО прикольная, я потом отдельно статью напишу.
2) не вижу очень уж большой разницы. Если я не ошибаюсь SCGI бинарный, но нет нативной поддержки nginxа (есть модули вроде). Но я почитаю, обещаю.
3) libfcgi, boost::asio
4) на первом месте стоит производительность, на втором масштабируемость.
я фанат плюсов, было бы побольше времени в сутках написал бы все на плюсах)))
я не думаю, что на каждую идею надо писать модуль и тем более я не думаю, что выигрыш по производительности будет колоссальный, я даже думаю он будет значительно меньше, чем кажется.
когда я еще начинал кодить, мне тоже казалось что все быстрые программки надо писать в виде LKM.
Как я понял…
Плюсовый код, если у него не выставлена сессия должен
грузить, что то типа 127.0.0.1/start_session.php,
где ему будет возвращаться PHPSESSID,
и он его будет ставить в куки текущего соединения.
По мне так решение должно быть красивым и максимально быстрым.
Но тут ни того ни другого, но суть даже не в этом —
если я уйду вообще от php и такого понятия как PHPSESSID в моей системе больше не будет, в вашем случае мне все равно придется писать аналогичный код.
нет.
смысл не в том, чтобы узнать PHPSESSID, а в том чтобы и php-бэкенд и плюсовый сервер идентифицировали пользователя идентичным идентификатором идентификации :)
вот так я и не хотел делать, я завязываюсь на определенную архитектуру,
и получается генерация идентификатора (в вашем случае сессии) будет в двух местах.
Данный модуль немного по другому работает, он ставит куку уже после отработки бэкенда.
Т.е. он возвращает ее броузеру, а бэкэнд в этот момент ничего не знает о uid. Т.е. первый запрос в бэкэнд будет ошибочен, что не допустимо.
SID присутствует, а uid нет… честно честно модуль userid включен)
Я много где спараноил)))
Думаю использовать /dev/urandom — псевдослучайные, видимо к этому придется прийти.
Я читал ман и видел описания функции, так что когда я делал бенчмарк, то специально проверил — ~50Mb в секунду выдает /dev/random, и затыков я не обнаружил.
Хотя может еще конечно и наткнусь.
Если использовать перловый rand(), то время работы увеличивается в 6 раз — только что проверил.
И его значительно дольше кастомайзить, чем например qqFileUploader.
А по юзабилити конечно круто.
далеко не последние версии gcc упорно варнингами сыплют, что printf без формата вывода вызывается.
со второй проблемой уже все наелись, во многих книжках и статьях атака %n детально расписана.
ИМХО, если человек бездумно пишет код на плюсах, он и до использования printf забажет все нафиг.
первая статья была интереснее.
давайте напишем сайт на php, прикрутим nginx, php-fpm, eaccelator, hip-hop, memcache и т.д. и т.п.
я конечно люблю пых, но есть очень прикольная серия статей www.insight-it.ru/highload/ один из смыслов которой «мы использовали пых, потому что так сложились обстоятельства».
1) там такая штука большая и ИМХО прикольная, я потом отдельно статью напишу.
2) не вижу очень уж большой разницы. Если я не ошибаюсь SCGI бинарный, но нет нативной поддержки nginxа (есть модули вроде). Но я почитаю, обещаю.
3) libfcgi, boost::asio
4) на первом месте стоит производительность, на втором масштабируемость.
я фанат плюсов, было бы побольше времени в сутках написал бы все на плюсах)))
когда я еще начинал кодить, мне тоже казалось что все быстрые программки надо писать в виде LKM.
peace — V
Плюсовый код, если у него не выставлена сессия должен
грузить, что то типа 127.0.0.1/start_session.php,
где ему будет возвращаться PHPSESSID,
и он его будет ставить в куки текущего соединения.
По мне так решение должно быть красивым и максимально быстрым.
Но тут ни того ни другого, но суть даже не в этом —
если я уйду вообще от php и такого понятия как PHPSESSID в моей системе больше не будет, в вашем случае мне все равно придется писать аналогичный код.
Но все равно спасибо и с праздником.
смысл не в том, чтобы узнать PHPSESSID, а в том чтобы и php-бэкенд и плюсовый сервер идентифицировали пользователя идентичным идентификатором идентификации :)
я бился с этим модулем какое-то время, так и не получилось заставить его делать что мне надо. к великому моему сожалению.
и получается генерация идентификатора (в вашем случае сессии) будет в двух местах.
Т.е. он возвращает ее броузеру, а бэкэнд в этот момент ничего не знает о uid. Т.е. первый запрос в бэкэнд будет ошибочен, что не допустимо.
SID присутствует, а uid нет… честно честно модуль userid включен)
Array ( [GLOBALS] => Array *RECURSION* [_POST] => Array ( ) [_GET] => Array ( ) [_COOKIE] => Array ( ) [_FILES] => Array ( ) [_SERVER] => Array ( [PHP_FCGI_MAX_REQUESTS] => 1000 [PHP_FCGI_CHILDREN] => 5 [USER] => www [PATH] => /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin [FCGI_ROLE] => RESPONDER [SCRIPT_FILENAME] => /usr/local/nginx/html/www//index.php [QUERY_STRING] => [REQUEST_METHOD] => GET [CONTENT_TYPE] => [CONTENT_LENGTH] => [SCRIPT_NAME] => /index.php [REQUEST_URI] => /index.php [DOCUMENT_URI] => /index.php [DOCUMENT_ROOT] => /usr/local/nginx/html/www [SERVER_PROTOCOL] => HTTP/1.1 [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_SOFTWARE] => nginx/1.1.12 [REMOTE_ADDR] => 127.0.0.1 [REMOTE_PORT] => 60816 [SERVER_ADDR] => 127.0.0.1 [SERVER_PORT] => 80 [SERVER_NAME] => localhost [REDIRECT_STATUS] => 200 [SID] => adb95450d71c9cbd5f1ecc97343256e19401c78b586585c3e969cc882a12744c [HTTP_HOST] => 62.109.16.240 [HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.23) Gecko/20110920 Firefox/3.6.23 s024vp [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [HTTP_ACCEPT_LANGUAGE] => ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 [HTTP_ACCEPT_ENCODING] => gzip,deflate [HTTP_ACCEPT_CHARSET] => windows-1251,utf-8;q=0.7,*;q=0.7 [HTTP_KEEP_ALIVE] => 115 [HTTP_CONNECTION] => keep-alive [PHP_SELF] => /index.php [REQUEST_TIME] => 1325859793 ) [_ENV] => Array ( ) [_REQUEST] => Array ( ) )Думаю на сервере основной генератор энтропии все же сетевуха.
ну я думаю из urandom достаточно будет
Думаю использовать /dev/urandom — псевдослучайные, видимо к этому придется прийти.
Я читал ман и видел описания функции, так что когда я делал бенчмарк, то специально проверил — ~50Mb в секунду выдает /dev/random, и затыков я не обнаружил.
Хотя может еще конечно и наткнусь.
Если использовать перловый rand(), то время работы увеличивается в 6 раз — только что проверил.