19 ноября, понедельник 15:01
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Проблемы со связью

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Проблемы со связью

    Народ есть предложение вот в этой теме собрать весь опыт по решению проблем со связью между ПОСами и Банком. От себя скажу, что у меня тут фактически что ни терминал - то повод для кретивного решения проблемы а-ля "какого чёрта он не дозванивается". Причём причины абсолютно разные бывают.

    Начну я с самой первой и запомнившейся мне проблемы:

    Ставил я ПОС в точку где есть внутренняя АТС и выход в город через "9". ПОС мой никак до банка не дозванивался. Проверил все настройки - всё ОК, вызвал мастера, который их АТС монтировал - тот нифига не знает. Думал всё - а чё оказалось, знаете. Их АТС с какого-то перепуга требовала перерыва между набором "9" и номера. В настройках перерыва небыло тк и АТСник и мои техники утверждали, что все современные АТС позволяют набирать подряд. И надоже именно та АТС была такой глючной (АТС LG точное название модели не помню) из-за чего в линию ПОС набирал только три последние цифры номера, предидущие АТС не пропускала "подвисая" в своём перерыве после "9"

    Сейчас вот опять интересная проблема - при звонке ПОСом на модем идёт отбой на городской АТС (телефоном на модем прозваниваюсь нормально). Сейчас иду выяснять эту тему - когда всё налажу напишу чё было

  • #2
    Еще бывает, что dial tone не сразу появляется. Та же проблема. Просто лучше всего сначала проверять что POS созванивается корректно и правильно настраивать все таймауты с помощью AT-команд и логики работы. Чем все
    это будет конфигурабельнее, тем лучше.
    Nick_st

    Комментарий


    • #3
      Ingibitor

      Паузы перед номером, после номера, между "девяткой" и номером, даже между цифрами номера - т.е. номер в ПОСе выглядит так: "5,5,5,2,2,3,3".
      Иногда АТС перед коммутацией выдает "улюлюканье", треск, щелчки и т.п., что требует запятых _после_ номера.
      Иногда ПОС нужно ставить с параллельным телефоном (чтобы нагрузить линию), иногда - наоборот, все параллельные телефоны включить после ПОСа. Иногда нужно отключать детект диалтона.

      Короче, возьмите себе инженера из бывших фидошников.

      Еще более животрепещущая тема - как подключить ПОС, когда автоматизаторы банка сами не знают, как у них настроено коммуникационное оборудование, когда на стыках типа "TCP - async" или "async - X.25 - async" чьи-то шаловливые ручонки настроили слишком маленькую или слишком большую скорость на асинке, когда при проектировании сети TCP постулируется прозрачным, но задержки в TCP-сети превышают все мыслимые пределы, а стек протоколов при этом выглядит в стиле "DLC (lev.2) over TCP over PPP", с какими-то наркоманскими преобразованиями и инкапсулированиями протоколов по пути...

      В общем, "не лей мне чай на спину".

      Комментарий


      • #4
        Ingibitor
        Тип терминала какой? Если OMNI-395, или что-то с таким же модемом - тут еще и глюки модема добавляются. А насчет линии - там часто вместо 60 вольт на линии 20 и диалтон в упор не видится. Самое плохое - когда напряжение скачет в зависимости от фазы луны вокруг deadline и постоянных параметров просто нет. Я бы организационно проблему решил - пошел к тамошнему начальству и попросил выдать линию получше, да еще с приоритетом по выходу в город.

        Комментарий


        • #5
          Самое неприятное, регулярно теряются символы из первой половины таблицы ASCII.
          <%(

          Комментарий


          • #6
            VMS

            Самое неприятное, регулярно теряются символы из первой половины таблицы ASCII.

            Эт' да, к этому мы привыкши. Телнет - он, в принципе, прозрачный, но не совсем.

            Прикол был более крышесрывающий. Есть такая классная вещь, как KCS. Не будем о грустном, будем о веселом. Так вот, на его авторизационном модуле я однажды наблюдал офигительнейшую картину.

            Терминал ставится в отделении банка. Тамошний спец проводит сделку на копейку. KCS формирует ответ на авторизацию с контрольной суммой 0Dh. Какая-то жадная циска по дороге видит знакомую букву и жадно ее ест. Терминал не получает контрольной суммы и делает перепосылку. Сколько-то там попыток, отваливаемся. Спец пытается еще раз. Той же карточкой, на ту же сумму. KCS формирует ответ, по каким-то неведомым мне причинам генерируя код авторизации таким образом, чтобы контрольная сумма осталась неизменной. 0Dh. Циска жрет. Терминал отваливается. Спец пробует еще раз. Опять на копейку. KCS не дремлет. Опять 0Dh. Циска в восторге. Спец в трансе.

            В итоге я вижу логи KCS, в которых белым по синему - ...дцать попыток авторизации на одну и ту же сумму по одной и той же карте и столько же успешных ответов с разными кодами авторизации, но одинаковой контрольной суммой.

            Мотивы людей, спроектировавших или запрограммировавших такую фичу (я о KCS, а не о циске), мне непонятны до сих пор.
            Может, знает кто? Для расширения кругозора - просветите, а?

            Комментарий


            • #7
              McSeem

              SET 0:0,1:0,2:0,3:0,4:5 на PAD-е Вас спасут.
              Мотивы людей, спроектировавших или запрограммировавших такую фичу (я о KCS, а не о циске), мне непонятны до сих пор.
              А мотивы просты - с одной точки зрения,упрощениие алгоритмов формирования/проверки контрольной суммы, а с другой - ЛЕНЬ Наверно, вторая точка зрения у McSeem возобладает [/B]

              Комментарий


              • #8
                Alison

                SET 0:0,1:0,2:0,3:0,4:5 на PAD-е Вас спасут.

                Те девайсы, к которым я имею доступ, работают нормально, спасибо.
                И там, на самом деле, был не X.25, а просто Telnet over TCP.

                А мотивы просты - с одной точки зрения,упрощениие алгоритмов формирования/проверки контрольной суммы, а с другой - ЛЕНЬ Наверно, вторая точка зрения у McSeem возобладает

                "Кто на ком стоял?" (с).

                Алгоритм формирования/проверки LRC (в том случае именно LRC) во-первых, не варьируется, а во-вторых, и так прост дальше некуда. Вопрос в следующем: зачем смешивать седьмой уровень со вторым, варьируя значение поля (в данном случае AuthCode) таким образом, чтобы ответы на одинаковые запросы были разными, но с одинаковой контрольной суммой? Это либо невероятно странный побочный эффект (от чего, интересно?), либо сознательно запрограммированный механизм. На всех ответах контрольная сумма посчитана правильно, и везде она одинакова, то есть сообщение специально формировалось таким образом, чтобы LRC оставалось постоянным.
                Для чего так усложнять алгоритм работы, мне непонятно.

                Во всяком случае, лень здесь ни при чем. Разве только в невнимательном чтении моего предыдущего сообщения.

                Комментарий


                • #9
                  McSeem
                  Во всяком случае, лень здесь ни при чем. Разве только в невнимательном чтении моего предыдущего сообщения.
                  Грешен... невнимательность имеется В принципе, LRC сдуру могут считать и не по всем полям сообщения, или номер транзакции от терминала настолько хитро увеличиватся на 1 вместе с кодом авторизации, что контрольная сумма может и совпадать "нечаянно" в течении длительного периода.

                  Комментарий


                  • #10
                    Alison
                    В принципе, LRC сдуру могут считать и не по всем полям сообщения, или номер транзакции от терминала настолько хитро увеличиватся на 1 вместе с кодом авторизации, что контрольная сумма может и совпадать "нечаянно" в течении длительного периода.
                    Только что залез в логи годичной давности...

                    Все, оказывается, очень просто. Номер транзакции не инкрементировался, так как терминал считал, что у нас сбои коммуникаций. Код авторизации каждый раз был разным, но он присутствовал как в своем поле, так и в поле "Text message". XOR одного с другим давал ноль, в результате - постоянное LRC.
                    Спасибо товарищам из APACS за их замечательный протокол.

                    P.S. Действительно, лень была. Моя. При "разборе полетов".

                    Комментарий


                    • #11
                      Весело бывает когда LRC = 0.
                      Т.к. софт обычно пишется на C, а сообщения рассматривают
                      как текстовые (если протокол не на базе ISO8583, напр. SPDH), то становится
                      все плохо :-)

                      Правда со второго раза обычно проходит, т.к. поля меняются (seq.no. datetime)
                      Nick_st

                      Комментарий


                      • #12
                        Терминалы у меня только Хайперкомы Т7Р.

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

                        Комментарий


                        • #13
                          nick_st Коль, ты что-ли? Так не надо SPDH-ное сообщение как строку разбирать. Или это компасА?

                          Комментарий


                          • #14
                            Ingibitor
                            Уточни, что там за АТС.
                            Попробуй использовать внешний модем вместе с терминалом, на нем хотя бы услышишь, что происходит в линии.

                            Комментарий


                            • #15
                              Водяной

                              Гиперком Т7П со внешними девайсами работать не умеет. Internal modem only.

                              Ingibitor

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

                              Комментарий


                              • #16
                                vict
                                Не Compass'a, а INPASS'a - был просто у них такой глюк - сейчас исправили
                                Nick_st

                                Комментарий


                                • #17
                                  12 тысяч терминалов Омни, работают как часы, каждую ночь связываются с
                                  банковским центром, не считая авторизаций и update application.
                                  Правда телефонные линии не российские и с тоновым набором проблем нет....
                                  А что касается LRC то проверка явно слабая, достаточно нескольких четных
                                  сбоев, что при плохой линии вполне возможно и вы получите совершенно
                                  ложную информацию, нормальные протоколы используют только CRC2.
                                  И уж в любом случае нельзя пользоваться LRC как индикацией конца пакета....
                                  и считать что ноль - это конец строки....

                                  Комментарий


                                  • #18
                                    Shula
                                    Обычно LRC и не считают концом сообщения. Сообщение форматируется
                                    в STX, ... , ETX, для проверки целостности обычно используется MAC. Это надежнее любого кода выявляюшего ошибки (LRC, CRC), т.к. это хэш-функция с ключом. Хотя на первом этапе LRC анализируют, чтобы можно было проверить
                                    на наличие случайных ошибок. Вообще для параметрического обнаружения
                                    любого наперед заданного количества ошибок можно применять БЧХ-коды (которые исправляют ошибки или Рида-Малера коды исправляющие ошибки), но
                                    уж больно большие накладные расходы на реализацию операций в соответствующей группе, для реализации локаторов ошибок.

                                    В принципе в телелеметрии это давно применяют, но для POS-ов пока еще
                                    я не видел решений с кодами исправляющими ошибки.

                                    Хотя, это зависит от протокола нижнего уровня, м.б. и не требуется нагружать
                                    логику работы POS-а.
                                    Nick_st

                                    Комментарий


                                    • #19
                                      nick_st
                                      Ну ты сказал! Как говорит yak, у ларька за такие слова тебе бы морду набили
                                      До сих пор посы делались буржуями для их хороших линий (поэтому большинство встроенных модемов без корреции, чтобы не тратить лишнее время на handshake) и с дохлым процессором. Поэтому нет никакого смысла употреблять не самые примитивные алгоритмы ради 100 байт. Попробуй ради интереса софтом посчитать MAC для 100 байт на OMNI395 - посмотри сколько это займет времени.

                                      Комментарий


                                      • #20
                                        nick_st

                                        для проверки целостности обычно используется MAC

                                        MAC, вообще-то, предназначен не для решения коммуникационных проблем. И хотя его можно использовать и для этого, такое использование MAC в большей мере является побочным эффектом. Обычно же используют все же какую-то контрольную сумму (общее название FCS - frame check sequence).

                                        Ну сколько уже можно мешать в кучу разные вещи... Одни вон решение о сделке по получению EOT принимают, другие DLC'шные acknowledgement'ы (1 байт!) по TCP гоняют, третьи МАС проверяют для контроля ошибок в линии.
                                        "Усюди смерть, розруха"... (с) Лесь Поддерев'янський.

                                        Комментарий


                                        • #21
                                          Shula
                                          12 тысяч терминалов Омни, работают как часы, каждую ночь связываются с
                                          банковским центром, не считая авторизаций и update application.

                                          Можете пояснить, зачем они каждую ночь связываются? HandShake?

                                          По теме:
                                          Во-первых, название ЗА СВЯЗЬ БЕЗ БРАКА было бы импозантнее.
                                          Во-вторых - многое зависит от соединения между АТС. Бывают патовые пары АТС-АТС, через которые модемы не проходят. Иногда на современных АТС это делается сознательно, иногда на старых это получается само собой.
                                          В-третьих, если протокол кривой и операции теряются или клонируются, то нужно говорить о конкретном протоколе с его разработчиком. И, например, использование MAC в качестве хэш-функции для проверки целостности сообщения накладно, но вполне допустимо. Но, опять таки, всё зависит от разработчика.
                                          В-четвёртых: Обеспечить 100% гарантию обработки сбоев только в on-line невозможно. Цикл "передача-ожидание подтверждения о приёме" в принципе бесконечный и после некоторого количества кругов должен быть одной из сторон разорван.

                                          Комментарий


                                          • #22
                                            McSeem
                                            Речь не идет о том, чтобы MAC-ировать все сообщение. Это уже на
                                            прикладном уровне делается обычно. Я имел в виду, что тут возможно два
                                            варианта работы - либо ошибки будут (если плохая связь), тогда спасти может
                                            MAC-ирование как самый простой вариант решения (сразу двух зайцев убиваешь и защита от злоумышленников и от помех)- благо это уже везде
                                            реализовано, если нет, то какие-то коды обнаруживающие или исправляющие
                                            ошибки. LRC - тоже реализовано, хотя и ненадежно, т.к. функция равновесная
                                            и линейная, а чтобы лучше, то CRC, еще лучше, тогда Рида-Малера, БЧХ, но это уже накладно, но зато ошибки исправляет.

                                            За все надо платить - хочешь надежно, тогда медленно, быстро - не надежно
                                            Nick_st

                                            Комментарий


                                            • #23
                                              nick_st

                                              MAC - это одно из полей сообщения, формат которого определен протоколом прикладного уровня. А контроль ошибок и перезапросы - это функция протокола канального уровня. Если использовать MAC для контроля ошибок, то по несовпадению MAC следует инициировать перезапрос кадра (именно кадра, так как такое понятие как "перезапрос сообщения" мне неизвестно. Если не считать APACS, конечно, где все смешано в кучу). Я бы это назвал инцестом в стеке протоколов.

                                              Насчет ненадежности LRC - не спорю. Вы же видели выше мои эмоции по поводу этого дурдома с одинаковым LRC.

                                              CRC16, на мой взгляд, хватит. С избыточным кодированием я на практике дела не имел, так что, откровенно говоря, не знаю, как оно получится...

                                              Блин, а с чего началось - человек-то всего лишь модем терминала хотел настроить...

                                              Комментарий


                                              • #24
                                                Класс, обсуждение мне нравится

                                                Насчёт темы согласен- ЗА СВЯЗЬ БЕЗ БРАКА мне нравиться, но не думаю, что правила форума позволят мне её поменять.

                                                Продолжаю историю про свой недозванивающийся терминал.

                                                Он так и не дозванивается собака. Проверили - он сам работает железно во всех режимах со всех доступных нам пульсовых и тоновых линий.

                                                Сейчас инженеры сделали специальную "слушалку" для линии (клёвый девайс получился) бум слушать ответ АТС. Чё там происходит тайна пока не послушаем.

                                                Напомню, что висим мы с точкой на одной АТС

                                                Комментарий


                                                • #25
                                                  Ingibitor
                                                  Напомню, что висим мы с точкой на одной АТС
                                                  Жаргон - это сила!
                                                  На "умных" модемах есть индикация уровня принимаемого сигнала и соотношения сигнал/шум в линии. Иногда телефонисты, выполнив процедуру с (см. выше) дивным названием "сменить пару", существенно улучшают ситуацию.

                                                  Комментарий


                                                  • #26
                                                    #paul
                                                    На "умных" модемах есть индикация уровня принимаемого сигнала и соотношения сигнал/шум в линии. Иногда телефонисты, выполнив процедуру с (см. выше) дивным названием "сменить пару", существенно улучшают ситуацию.
                                                    Можно также налить С2Н5ОН телефонистам, чтобы они все скрутки убрали с существущей пары от мини АТС. А насчет "умных" модемов - они отнюдь не гарантия успешного "спаривания" - 2 РАЗВЕСИСТЫХ тайнета не могли повязаться в очень специфических условиях - 2 куска меди на последней миле, а между ними - волокно. Преобразовательное оборудование вертело фазы так, что оставалось только смотреть на индикаторы и констатировать, что "больной перед смертью потел"

                                                    Комментарий


                                                    • #27
                                                      По поводу проблем со связью. Один московский банк вот уже как месяца два подключает ПОСЫ по сотовой связи. В чем здесь преимущество, я думаю говорить не надо. А самое главное, что при умном подходе, для банка данный вид связи бесплатен

                                                      Комментарий


                                                      • #28
                                                        Unregistered

                                                        А самое главное, что при умном подходе, для банка данный вид связи бесплатен

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

                                                        Комментарий


                                                        • #29
                                                          McSeem

                                                          Скорее второе. При дозвоне с сотового на сотовый, входящие звонки бесплатны, а у БИЛАЙНА карту можно вообще 60 дней не активизировать, все равно дозвон будет

                                                          Комментарий


                                                          • #30
                                                            McSeem

                                                            Скорее второе. При дозвоне с сотового на сотовый, входящие звонки бесплатны, а у БИЛАЙНА карту можно вообще 60 дней не активизировать, все равно дозвон будет

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X