На счет СПД. Если вам платят через SWIFT, то он (точнее банк-корреспондент) берет комиссию $1. И, хоть это не ваши деньги, вы на них, на этот один бакс, должны вовремя сделать соответствующий СПД с другим кодом.
И хорошо бы, если бы менеджеры Тинькова меня об этом предупредили. Предупредили, но через год. В итоге отчетность автоматом ушла в налоговую -> сработали роботы -> дело, штрафы как злостному уклонисту (просрочка +неоднократно) -> попал на ~90К.
По поводу проходных RJ45 соединителей, был негативный опыт на проходной патч-панели в сумме портов на триста. Процентов 10 из них через неделю… месяц перестали контачить; не помогают и пластиковые язычки коннекторов.
Рекомендую такие соединители, если они неизбежны, законтрить изолентой (через 5 лет может высохнуть), а лучше медной проволокой.
Ждем рассказа про устройство «голов» и применяющиеся технологии обеспечения отказоустойчивости.
Также, что вы думаете на счет «импортозамещения» шпиндельных дисков.
Возможно, но тогда бы обе мои таблицы распределения единиц выглядели (сверху вниз) бы как последовательности 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 и так далее, что сорвало бы крышу у большинства читателей.
Для начала, Little endian/Big endian имеет отношение только к порядку байт и только при их сетевой передаче, причем тогда, когда передаются числа типа short и long. Не наш случай. МАС адрес-просто последовательность из 6 идущих подряд байт, без всяких трюков по их перестановке.
Биты в байте (в его двоичном представлении) принято именовать справа налево, от младших бит к старшим потому, что младшие биты отвечают за меньшие, в алгебраическом смысле, числа. Считать же биты можно как угодно, и поскольку мы находимся в регионе, где в письме и чтении принят порядок слева направо, я считаю биты в байтах с первого слева. Тем более такой способ разумен, когда в контексте статьи обсуждаем последовательности из 48 бит, идущих подряд с первого по шестой байт слева направо.
Здесь все о очень просто. Если у вас две сетевые карты имеют одинаковый МАС адрес в одном сетевом сегменте (влане), то с точки зрения коммутатора, который этот сегмент (VLAN) обслуживает, будет наблюдаться эффект «mac flapping». По сути это «прыгание» адреса между портами. Что с этим будет коммутатор делать-зависит от вендора. В большинстве случаев — просто обновлять свою таблицу коммутации. Можно настроить блокировку, вот например.
Не пользуйтесь вайфаем в метро, да и вообще в публичных местах, пока повсеместно не внедрят Hotspot 2.0.
Все гостевые сервисы должны привязывать МАС к номеру телефона. Однако тот закон не регулирует механику передачу привязки товарищу майору. На практике интеграция авторизации с СОРМ реализована только у крупных операторов.
Мы, разработчики WNAM, обеспечивали Wi-Fi авторизацию в Лужниках, и ещё на 9 стадионах и 5 фан-зонах ЧМ.
Проблема с очередями СМС возникала только здесь, на трёх матчах. Технически это выглядело как неполучение нашим kannel'ом подтверждения о приёме СМС от провайдера (submit_sm_resp) в ответ на наш submit_sm. Соответственно отправляемое СМС помещалось в очередь, которая росла. В нормальном режиме такое подтверждение приходит за миллисекунды (сама доставка затем занимает от 1 до 60 секунд, для большинства россиян — до 5 секунд). Иногда, может и через несколько минут, приходит пачка подтверждений submit_sm_resp, иногда и ничего. Наш kannel периодически повторял попытки отправки.
Что характерно, TCP-соединение SMPP не рвалось. Провайдер, конечно, нас уверял, что у него все замечательно, что его система и не такие потоки выдерживает, проверьте файрволл, проверьте конфиги, перезагрузите винду — но факт проблемы был налицо, а конструктивного траблшутинга в итоге не получилось. С другими провайдерами, да и с тем же на других матчах, подобных проблем не было.
Пиковая нагрузка была порядка 50 смс/сек, что конечно мелочи.
1. Куки в минибраузерах всплывающих не запоминаются.
2. Редирект https-это всегда ошибка сертификта, каким бы он валидным не был. Потому что для устройства это MITM атака.
Все упирается в несовершенство самих методов авторизации и аутентификации у операторов связи
Все упирается в несовершенство изобретенной лет 20 назад технологии, в которой идентификацию можно произвести только через привязку к МАС адресу, который, увы, можно сменить.
А вообще решение есть-использовать wi-fi оборудование, умеющее Hotspot 2.0, eap-sim и соотвествующий софт на стороне провайдера. Вот только микротики (а их процентов 80 среди хотспотов) такого не могут, нормального софта для реализации этой схемы не существуют, а провайдеры в РФ ленятся.
Соглашусь, но когда приходит готовый дизайн за 2 дня «до», и в шаблон страницы встроен (base64) шрифт размером полмегабайта, приходится выкручиваться :)
В системе WNAM на этот счет есть соответствующие лимиты и блокировки.
Что касается доставки СМС международным получателям, проблема возникает только у некоторых иностранных операторов с буквенными идентификаторами отправителя (их ведь согласовывать обычно надо). На КК меньше всего везло чилийцам.
Даю бесплатный совет: рандомизированные MAC адреса можно отличить по седьмому биту первого байта.
По моим сведениям, в среднем не более 5% посетителей ТРЦ проходят идентификацию и подключаются к бесплатному вайфаю.
Подождите, нам сейчас расскажут про фингерпринтинг, прометки, бигдату и блокчеин.
Действительно, из анализа radiotap header можно извлечь некоторую дополнительную информацию об устройстве, но для однозначной его привязке к известному ранее профиль посетителя её мало.
Описываемые технологии могут с некоторой степенью достоверности показать «степень вовлеченности», то есть отношение посетителей, которые долго были рядом с точкой доступа к тем, что прошли мимо, а также графики «наплыва» посетителей, в общем все, что связано не с девайсом, а со временем. Однако маркетинговая ценность этого сомнительна: владельцы HoReCa бизнесов эти цифры и без того давно знают, так что дополнительно платить за такого рода «аналитику» желающих найдется немного. То есть, конечно, поведутся и найдутся, но скоро разочаруются.
К сожалению, повсеместная рандомизация МАС адресов устройств в beacon пакетах сводит к нулю попытки связать запись об известном посетителе (с реальным МАС и номером телефона) с ним же, когда тот просто ходит вокруг точки-сенсора и не достает телефон из кармана. Достоверную аналитику и CRM на таком не построить. Если, конечно, сенсор не прикидывается MT_FREE и не заставляет устройство светить свой реальный адрес.
И хорошо бы, если бы менеджеры Тинькова меня об этом предупредили. Предупредили, но через год. В итоге отчетность автоматом ушла в налоговую -> сработали роботы -> дело, штрафы как злостному уклонисту (просрочка +неоднократно) -> попал на ~90К.
Рекомендую такие соединители, если они неизбежны, законтрить изолентой (через 5 лет может высохнуть), а лучше медной проволокой.
Также, что вы думаете на счет «импортозамещения» шпиндельных дисков.
Для начала, Little endian/Big endian имеет отношение только к порядку байт и только при их сетевой передаче, причем тогда, когда передаются числа типа short и long. Не наш случай. МАС адрес-просто последовательность из 6 идущих подряд байт, без всяких трюков по их перестановке.
Биты в байте (в его двоичном представлении) принято именовать справа налево, от младших бит к старшим потому, что младшие биты отвечают за меньшие, в алгебраическом смысле, числа. Считать же биты можно как угодно, и поскольку мы находимся в регионе, где в письме и чтении принят порядок слева направо, я считаю биты в байтах с первого слева. Тем более такой способ разумен, когда в контексте статьи обсуждаем последовательности из 48 бит, идущих подряд с первого по шестой байт слева направо.
Все гостевые сервисы должны привязывать МАС к номеру телефона. Однако тот закон не регулирует механику передачу привязки товарищу майору. На практике интеграция авторизации с СОРМ реализована только у крупных операторов.
Проблема с очередями СМС возникала только здесь, на трёх матчах. Технически это выглядело как неполучение нашим kannel'ом подтверждения о приёме СМС от провайдера (submit_sm_resp) в ответ на наш submit_sm. Соответственно отправляемое СМС помещалось в очередь, которая росла. В нормальном режиме такое подтверждение приходит за миллисекунды (сама доставка затем занимает от 1 до 60 секунд, для большинства россиян — до 5 секунд). Иногда, может и через несколько минут, приходит пачка подтверждений submit_sm_resp, иногда и ничего. Наш kannel периодически повторял попытки отправки.
Что характерно, TCP-соединение SMPP не рвалось. Провайдер, конечно, нас уверял, что у него все замечательно, что его система и не такие потоки выдерживает, проверьте файрволл, проверьте конфиги,
перезагрузите винду— но факт проблемы был налицо, а конструктивного траблшутинга в итоге не получилось. С другими провайдерами, да и с тем же на других матчах, подобных проблем не было.Пиковая нагрузка была порядка 50 смс/сек, что конечно мелочи.
2. Редирект https-это всегда ошибка сертификта, каким бы он валидным не был. Потому что для устройства это MITM атака.
Все упирается в несовершенство изобретенной лет 20 назад технологии, в которой идентификацию можно произвести только через привязку к МАС адресу, который, увы, можно сменить.
А вообще решение есть-использовать wi-fi оборудование, умеющее Hotspot 2.0, eap-sim и соотвествующий софт на стороне провайдера. Вот только микротики (а их процентов 80 среди хотспотов) такого не могут, нормального софта для реализации этой схемы не существуют, а провайдеры в РФ ленятся.
Что касается доставки СМС международным получателям, проблема возникает только у некоторых иностранных операторов с буквенными идентификаторами отправителя (их ведь согласовывать обычно надо). На КК меньше всего везло чилийцам.
По моим сведениям, в среднем не более 5% посетителей ТРЦ проходят идентификацию и подключаются к бесплатному вайфаю.
Действительно, из анализа radiotap header можно извлечь некоторую дополнительную информацию об устройстве, но для однозначной его привязке к известному ранее профиль посетителя её мало.
Описываемые технологии могут с некоторой степенью достоверности показать «степень вовлеченности», то есть отношение посетителей, которые долго были рядом с точкой доступа к тем, что прошли мимо, а также графики «наплыва» посетителей, в общем все, что связано не с девайсом, а со временем. Однако маркетинговая ценность этого сомнительна: владельцы HoReCa бизнесов эти цифры и без того давно знают, так что дополнительно платить за такого рода «аналитику» желающих найдется немного. То есть, конечно, поведутся и найдутся, но скоро разочаруются.