Программный интерфейс в виде приложения для смартфона с картой по этому NFC пообщается и код покажет.
Т.е. для подтверждения действия с телефона, нужно использовать приложение на телефоне? А давайте просто будем посылать SMS/Push'и на этот телефон и не напрягать пользователя отдельным приложением. Упс... кажется я где-то видел.
Онлайн-платежи (кроме супер доверенных марчантов вроде Amazon, Uber и т.п.) тоже нужно подтверждать через кардридер. (MasterCard 3d-secure).
Позанудствую, но 3D Secure просит не банк, а продавец. Т.е. Amazon не просит не потому что он такой доверенный весь из себя, а потому что он для удобства клиентов готов сам нести риски фрода. Остальным - гораздо проще (и дешевле) заюзать 3D Secure.
Как-то звонил провайдеру с проблемой, а т.к. чтобы прорваться через первую линию службы поддержки надо сказать код ошибки PPPoE, говорил всегда какой-нибудь левый, чтобы скрипт сломался. В итоге добрался до какого-то крутого дядьки, который мне звонил на личный номер со статусом — я тут мимо прохожу, давай зайду, никогда такой проблемы не видел.
Проблема оказалась в пережатом столом проводе, что давало линк, но и ничего больше.
Ведь заполненность в 100% бывает только в одном случае - мест на всех не хватило, и куча народа, условно говоря, осталась на вокзале. Т.е. полетела самолетом, поехала автомобилем или отказалась от поездки вообще. Что означает для РЖД упущенную прибыль.
Позанудствую. Для некоторых направлений заполненность может сильно варьироваться от дня недели, времени суток или самого направления. Т.е. возьмём условный поезд Москва-Нью Васюки. В пятницу вечером все ломятся из Москвы, заполненность 100%, назад - полупустой поезд. В понедельник с утра - всё наоборот. На неделе - обычная средняя загрузка. Из решений тут только тасовать количество вагонов, но с учётом того, что покупается конкретное место в конкретном вагоне — это весьма мутная логистическая задача.
Так что иметь возможность запихать больше пассажиров в вагон — идея для РЖД вполне здравая, т.к. позволит заработать больше в пиковых ситуациях.
Так говорить можно. Но если у кого-то не совпадает — значит что-то нечисто. Т.е. если организатор сказал лажу — это проблемы организатора. Все будут считать что прослушивают или организатора или его, а после обсуждения - выяснят, что прослушивают организатора.
Да, есть. SvcHostSplitThresholdInKB, если что, это сделано для надёжности (один падающий сервис не будет за собой все связанные тащить) и прозрачности (явно видно, кто плохо себя ведёт). Ну и в технических моментах тоже лучше. Побочка: жрёт гораздо больше памяти.
Если что, они ещё добавли Per-user service, т.е. сервисы, создающиеся спеацильно для пользователя, что тоже добавляет процессов и отжирает память.
Я так понял, что из-за того, что в будущем у вас будут проблемы (вас заставят прогнуться и вставлять рекламу), вам надо сделать платную версию, и жить от денег пользователей.
Это моя попытка осмыслить комментарий merhalak, а не мнение.
В своё время у Тинькова в приложении (в банке?) был баг с часовыми поясами. Был в стране, где время +1 от Москвы и в приложении все операции показывались только через час после совершения.
не верю :-) даже на самом китайском андроиде есть IKEv2 или какой-нибудь IPsec. Проверьте, пожалуйста, еще раз
Не буду делать скриншот, но есть:
PPTP, L2TP, L2TP/IPSec PSK, L2TP/IPSec RSA, IPSec XAuth PSK, IPSec XAuth RSA, IPSec Hybrid RSA.
Именно IKEv2 нету. Пользуюсь как раз «каким-нить» IPSec
Ну, автор статьи тоже радует :) А если в такой туннель завернуть ICMP, то и мониторинг внешних ресурсов также будет стабильнее. Давайте заменим один протокол другим, чтобы было стабильнее. А может сразу тогда использовать другой?
В общем, у автора свое видение проблемы, а тесты у него уж очень прямолинейные.
Он концептуально не может некоторые вещи сделать. Представьте разговор по условному Скайпу. Потерялся пакет — ну и фиг с ним, собеседник чуть хрюкнул, а тут поставится всё на паузу, пока повторный не придёт. Т.е. все ситуации, где UDP вводят ради скорости, ценой допустимых потерь — начинают вести себя плохо.
Тут можно ещё добавить, что в одном TCP-потоке множество соединений и страдать будут все.
А вот если реально плохая связь, то там может очень сильно всё нарастать (ретрансмиты внутри и снаружи туннеля).
Но вот то, что снаружи это фактически HTTPS (хотя и с неестественным профилем трафика) — это огромный плюс. Ну и второй плюс, что из-за этого, это самый стабильный VPN, пролезающий через любые наты.
А с HTTP3, боюсь, что к тому времени в России просто запретят UDP, как нежелательный протокол :)
Отвечу про SSTP. У него главный недостаток — TCP. Для туннелей это очень неправильно. HOL, потери пакетов и всё такое. В целом жить можно, но если связь не очень хорошая, то начинают сильно эскалироваться проблемы. Ну и накладные расходы из-за этого выше.
Ну, на самом деле тут пытаются решить одну из проблем, связанную с высоким DPI (ещё и динамичным). Когда непонятно, какой размер в пикселях будет у окна и чтобы не было мыла.
При этом пытаются усидеть на куче стульев, чтобы и планшеты с тачскрином, и ноутбуки, и десктопы, всё было хорошо. Заодно новомодные технологии с примесью легаси и получаем то, что получаем. Всё тормозит, неудобно, но при дефолтных настройках — красиво.
А я от злости начал править сейвы, выправляя после каждой миссии характеристики назад, но потом понял, что я открыл ящик Пандоры, и у меня по миссии ходила толпа убер-солдат, которые силой мысли захватывали всё что шевелится.
У SSTP есть архитектурная проблема. Он работает через TCP, что для VPN'ов сильно не рекомендуется. Т.е. только как крайняя мера, когда всё остальное не работает (тут-то SSTP, косящий под https вполне вариант).
Проблема в том, что во-первых оверхед, а во-вторых весёлые проблемы при плохой связи. Т.е. на уровне IP потерять пакет — не проблема. Тут же его будут повторять, может получиться что внутренняя сеть посчитает пакет потерянным и повторит отправку, а снаружи будут его упорно доставлять. Т.е. хорошая эсклация трафика будет (а связь и так не фонтан).
Да-да. Давайте шифровать взаимодействие. Но для этого же нужно пароли/сертификаты/ключи где-то хранить, а это мы сразу попадаем на разборки с безопасниками. Ок. тогда не будем шифровать, нет паролей — нет проблем.
Т.е. для подтверждения действия с телефона, нужно использовать приложение на телефоне? А давайте просто будем посылать SMS/Push'и на этот телефон и не напрягать пользователя отдельным приложением. Упс... кажется я где-то видел.
Позанудствую, но 3D Secure просит не банк, а продавец. Т.е. Amazon не просит не потому что он такой доверенный весь из себя, а потому что он для удобства клиентов готов сам нести риски фрода. Остальным - гораздо проще (и дешевле) заюзать 3D Secure.
Как-то звонил провайдеру с проблемой, а т.к. чтобы прорваться через первую линию службы поддержки надо сказать код ошибки PPPoE, говорил всегда какой-нибудь левый, чтобы скрипт сломался. В итоге добрался до какого-то крутого дядьки, который мне звонил на личный номер со статусом — я тут мимо прохожу, давай зайду, никогда такой проблемы не видел.
Проблема оказалась в пережатом столом проводе, что давало линк, но и ничего больше.
Позанудствую. Для некоторых направлений заполненность может сильно варьироваться от дня недели, времени суток или самого направления. Т.е. возьмём условный поезд Москва-Нью Васюки. В пятницу вечером все ломятся из Москвы, заполненность 100%, назад - полупустой поезд. В понедельник с утра - всё наоборот. На неделе - обычная средняя загрузка. Из решений тут только тасовать количество вагонов, но с учётом того, что покупается конкретное место в конкретном вагоне — это весьма мутная логистическая задача.
Так что иметь возможность запихать больше пассажиров в вагон — идея для РЖД вполне здравая, т.к. позволит заработать больше в пиковых ситуациях.
Так говорить можно. Но если у кого-то не совпадает — значит что-то нечисто. Т.е. если организатор сказал лажу — это проблемы организатора. Все будут считать что прослушивают или организатора или его, а после обсуждения - выяснят, что прослушивают организатора.
Если что, они ещё добавли Per-user service, т.е. сервисы, создающиеся спеацильно для пользователя, что тоже добавляет процессов и отжирает память.
Это моя попытка осмыслить комментарий merhalak, а не мнение.
Не буду делать скриншот, но есть:
PPTP, L2TP, L2TP/IPSec PSK, L2TP/IPSec RSA, IPSec XAuth PSK, IPSec XAuth RSA, IPSec Hybrid RSA.
Именно IKEv2 нету. Пользуюсь как раз «каким-нить» IPSec
В общем, у автора свое видение проблемы, а тесты у него уж очень прямолинейные.
Тут можно ещё добавить, что в одном TCP-потоке множество соединений и страдать будут все.
А вот если реально плохая связь, то там может очень сильно всё нарастать (ретрансмиты внутри и снаружи туннеля).
Но вот то, что снаружи это фактически HTTPS (хотя и с неестественным профилем трафика) — это огромный плюс. Ну и второй плюс, что из-за этого, это самый стабильный VPN, пролезающий через любые наты.
А с HTTP3, боюсь, что к тому времени в России просто запретят UDP, как нежелательный протокол :)
На моём андроиде, кстати, его из коробки нет.
При этом пытаются усидеть на куче стульев, чтобы и планшеты с тачскрином, и ноутбуки, и десктопы, всё было хорошо. Заодно новомодные технологии с примесью легаси и получаем то, что получаем. Всё тормозит, неудобно, но при дефолтных настройках — красиво.
Проблема в том, что во-первых оверхед, а во-вторых весёлые проблемы при плохой связи. Т.е. на уровне IP потерять пакет — не проблема. Тут же его будут повторять, может получиться что внутренняя сеть посчитает пакет потерянным и повторит отправку, а снаружи будут его упорно доставлять. Т.е. хорошая эсклация трафика будет (а связь и так не фонтан).