Версии / исходники ПО CyberPlat: TerminalClient, Terminal Server, Вебклиент (Webclient)

[Thunderbaud]

там логику надо очень серьезно продумывать....можно создавать несколько очередей итд, но как я понял такого пока нету?

смотря что подразумевать под "очередью" !
В "другом продукте", о котором речь шла выше, логика такая (по МОЕМУ мнению, исходников не видел

1) под очередью подразумевался один поток обработки платежей; макс число очередей задается в конфиге, обычно их штук 50
2) приоритет загрузки свободной очереди отдается пакетам приходящим с терминалов
3) принятый пакет сразу же подвергается обработке; при ошибке ПС либо таймауте платеж получает статус "отложен", затем бертся следующий
4) с неким периодом в свободные очереди подгружаются ранее отложенные и снова пытаются провестись

И все хорошо, пока на шаге 3 не начинаются тормоза.
Если бы эти очереди имели привязку по провайдерам (типа 30 потоков Мегафон/20 потоков Билайн/10 Потоков МТС/5 потоков прочие) и распознавали ситуацию проблем с провайдером, на нормально работающих это бы не влияло. Полагаю, задача вполне решаемая.
А если препроцессинг еще сможет как-то извещать терминалы, что с провайдером XYZ начались затыки - так это вообще МЁД

Есть еще одна очень важная задача для успешной работы с предпроцессингом- дублирование сервера. Объяснять, думаю, не надо-чуть что с ним-и вся сеть легла. Как минимум, клиентский софт должен иметь настройки нескольких IP сервера, либо уметь перебирать их по DNS. Ну а с серверной стороны должен быть зеркалированный или кластеризованый SQL.

[MeisteR]

Thunderbaud, вот как раз с это проблемой столкнулись, на третьем шаге, если у кого то затык до 10 000 платежей в обработке, которые рассасываются к утру только.

[Thunderbaud]

Thunderbaud, вот как раз с это проблемой столкнулись, на третьем шаге, если у кого то затык до 10 000 платежей в обработке, которые рассасываются к утру только.

Уже на Киберовском софте, или на "другом хорошем порошке" ?

Кибер пока попробовать не дали. А на том я просто вручную отключаю в конфиге заглючевшего пров-а, меняю в базе статус платежей на него с 2 на 1 и перезапускаю сервак. Как провайдер поднимается-обратная операция (восстановление конфига и перезапуск). По крайней мере, страдают только клиенты одной компании, а не все.

[MeisteR]

Thunderbaud, вот как раз с это проблемой столкнулись, на третьем шаге, если у кого то затык до 10 000 платежей в обработке, которые рассасываются к утру только.

Уже на Киберовском софте, или на "другом хорошем порошке" ?

Кибер пока попробовать не дали. А на том я просто вручную отключаю в конфиге заглючевшего пров-а, меняю в базе статус платежей на него с 2 на 1 и перезапускаю сервак. Как провайдер поднимается-обратная операция (восстановление конфига и перезапуск). По крайней мере, страдают только клиенты одной компании, а не все.

Нет не на киберовском, на своем. Долго делали управление очередями, но вроде пока еще не оптимизировали по максимуму.

[Гость]

Кибер в тестовом режиме предлагает потестить систему предпроценнсинга - иначе говоря ПО типа ваши терминали, ваш сервер - все заявки уходят сначала на сервер а потом уже в кибер.
Можно собирать данные по своим поставщикам услуг.

Вопрос по предпроцессингу. Если его использовать, соответственно он будет отсылать все платежи со всех терминалов на одну зарегистрированную точку. Под одну точку в Кибере вроде выделено 50 каналов или потоков, не будет ли затыка при большом количестве терминалов и соответсвенно платежей. Или что будет если у одного из операторов будет затык по приему платежей, не будут ли они скапливаться в большую очередь?

1. Точной информации по нагрузоустойчивости пока нет, но предварительно 500 терминалов протянуть должна легко.
2. При затыке платежей никаких накладок серьезных быть не должно, т.к. в первую очередь выбираются платежи, которые дольше всех не выбирались.

[Гость]

там логику надо очень серьезно продумывать....можно создавать несколько очередей итд, но как я понял такого пока нету?

смотря что подразумевать под "очередью" !
В "другом продукте", о котором речь шла выше, логика такая (по МОЕМУ мнению, исходников не видел

1) под очередью подразумевался один поток обработки платежей; макс число очередей задается в конфиге, обычно их штук 50
2) приоритет загрузки свободной очереди отдается пакетам приходящим с терминалов
3) принятый пакет сразу же подвергается обработке; при ошибке ПС либо таймауте платеж получает статус "отложен", затем бертся следующий
4) с неким периодом в свободные очереди подгружаются ранее отложенные и снова пытаются провестись

И все хорошо, пока на шаге 3 не начинаются тормоза.
Если бы эти очереди имели привязку по провайдерам (типа 30 потоков Мегафон/20 потоков Билайн/10 Потоков МТС/5 потоков прочие) и распознавали ситуацию проблем с провайдером, на нормально работающих это бы не влияло. Полагаю, задача вполне решаемая.
А если препроцессинг еще сможет как-то извещать терминалы, что с провайдером XYZ начались затыки - так это вообще МЁД

Есть еще одна очень важная задача для успешной работы с предпроцессингом- дублирование сервера. Объяснять, думаю, не надо-чуть что с ним-и вся сеть легла. Как минимум, клиентский софт должен иметь настройки нескольких IP сервера, либо уметь перебирать их по DNS. Ну а с серверной стороны должен быть зеркалированный или кластеризованый SQL.

Все это возможно в разрабатываемой системе.

[Thunderbaud]

2. При затыке платежей никаких накладок серьезных быть не должно, т.к. в первую очередь выбираются платежи, которые дольше всех не выбирались.

Вот это не совсем ясно. Вот скопилась куча непрошедших. При этом продолжают поступать новые и новые. И что, они будут сначала попадать в "кучу", а сервер будет в первую очередь "долбить" самые старые из этой кучи, причем независимо от провайдера? При таком алгоритме мы и получим большой головняк...

[Гость]

2. При затыке платежей никаких накладок серьезных быть не должно, т.к. в первую очередь выбираются платежи, которые дольше всех не выбирались.

Вот это не совсем ясно. Вот скопилась куча непрошедших. При этом продолжают поступать новые и новые. И что, они будут сначала попадать в "кучу", а сервер будет в первую очередь "долбить" самые старые из этой кучи, причем независимо от провайдера? При таком алгоритме мы и получим большой головняк...

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

[Thunderbaud]

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

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

[MeisteR]

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

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

Присединяюсь к пожеланию об описании алгоритма

[Гость]

Присединяюсь к пожеланию об описании алгоритма

Если грубо, то так:

1. Выбираем N платежей, которые нужно провести, с самой старой меткой.
2. Ставим им в метку текущее время.
3. Проводим.
1. GOTO 1

[Thunderbaud]

1. GOTO 1

Троян типа "denial of service" получается ))

так что, никакого отсева и откладывания заглючившего провайдера не предусмотрено? Вот МТС регулярно падает так, что не "технологический перерыв", а "нет связи с сервером оператора" по таймауту.
При таком примитивном цикле возникнут задержки и по другим операторам. Не может же предпроцессинг одновременно проводить скопившихся 500 платежей. Запустит 50 thread'ов, и будут они ждать таймаута от МТС. А за это время терминалы еще платежей накидают, и вырастит снежный ком.

[MeisteR]

может сделать несколько паралельных очередей на отправку? Самы проблемные платежи запихивать во вторую и третью очереди?

[Гость]

1. GOTO 1

Троян типа "denial of service" получается ))

так что, никакого отсева и откладывания заглючившего провайдера не предусмотрено? Вот МТС регулярно падает так, что не "технологический перерыв", а "нет связи с сервером оператора" по таймауту.
При таком примитивном цикле возникнут задержки и по другим операторам. Не может же предпроцессинг одновременно проводить скопившихся 500 платежей. Запустит 50 thread'ов, и будут они ждать таймаута от МТС. А за это время терминалы еще платежей накидают, и вырастит снежный ком.

Вы упорно не понимаете о чем я говорю.
Ну как бы попроще... если ошибка у МТС-а вылезла на платеже, то в следующий раз этот платеж будет проводиться с задержкой, и чем долше не будет проходить тем долше задержка. Т.е. Да - по одному разу МТС-овские платежи будут стучаться, т.к. я не могу по ошибке в одних платежах делать вывод о том что другие не пройдут, но и все. В след. раз они будут дергаться только после того как все остальные, пришедшие за это время, проведутся.

[Гость]

может сделать несколько паралельных очередей на отправку? Самы проблемные платежи запихивать во вторую и третью очереди?

Именно этого алгоритм и достигает - чем дольше платеж не проходит, тем с большим периодом он пытается пройти.

[Thunderbaud]

Вы упорно не понимаете о чем я говорю.

ну почему же, понимаю. Реализован нарастающий таймаут между попытками. Условие необходимое, но недостаточное.

я не могу по ошибке в одних платежах делать вывод о том что другие не пройдут

А вот по моему, если пятьдесят платежей ПОДРЯД на одного провайдера не прошли с первой попытки, да еще с ошибкой "технологический перерыв", либо "нет связи с сервером опсоса"- есть повод задуматься.

Поэтому предлагаю дополнить такой функционал (если угодно-в виде отключаемой опции):

при непрохождении N платежей (число настраивается пользователем) подряд на одного провайдера, все последующие поступающие платежи на этого пров-ра НЕ пытаются провестись до тех пор, пока не будет проведен хотя бы один из N ранее ожидавших.

И еще у меня есть одно фундаментальное пожелание:
очень хотелось бы иметь комбинированную систему, в которой можно будет самостоятельно определять, какие типы платежей будут проводить сами терминалы, а какие пойдут через предпроцессинг.
IMHO, это позволит использовать плюсы обоих идеологий, работать с наименьшим риском для надежности.

[Гость]

Вы упорно не понимаете о чем я говорю.

ну почему же, понимаю. Реализован нарастающий таймаут между попытками. Условие необходимое, но недостаточное.

я не могу по ошибке в одних платежах делать вывод о том что другие не пройдут

А вот по моему, если пятьдесят платежей ПОДРЯД на одного провайдера не прошли с первой попытки, да еще с ошибкой "технологический перерыв", либо "нет связи с сервером опсоса"- есть повод задуматься.

Поэтому предлагаю дополнить такой функционал (если угодно-в виде отключаемой опции):

при непрохождении N платежей (число настраивается пользователем) подряд на одного провайдера, все последующие поступающие платежи на этого пров-ра НЕ пытаются провестись до тех пор, пока не будет проведен хотя бы один из N ранее ожидавших.

И еще у меня есть одно фундаментальное пожелание:
очень хотелось бы иметь комбинированную систему, в которой можно будет самостоятельно определять, какие типы платежей будут проводить сами терминалы, а какие пойдут через предпроцессинг.
IMHO, это позволит использовать плюсы обоих идеологий, работать с наименьшим риском для надежности.

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

По поводу второго - уже реализовано.
Можно 2 схемы на провайдеров назначать: вторая - сквозная, т.е. предпроцессинг работает как обычный шлюз (просто переподписывает запросы и ответы).
Также можно использовать 2-й набор ключей на вебклиенте и ряд операторов пустить через предпоцессинг, а остальные напрямую в киберплат

[Гость]

Почему-то на странице cyberplat.ru/terminal_pro/pro_files.html
ссылка "Исходные коды серверной части ПО" ведёт на исходники клиентской части.

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

[keyreal]

Проблема:
При закрытии клиентской части умирает серверная часть мониторинга.
ОС:
Windows XP
Описание:
Запускаем сервер, коннектимся клиентом к серверу (надо чтобы клиент что-то отобразил),
закрываем клиент - сервер выходит с ошибкой. Причина - 99% у вас установлен NOD32,
который имеет несовместимый интерфейс в работе с библиотеками .NET Remoting. Также
к данной ошибке приводить могут и другие антивирусные программы или сетевые службы.
Решение:
По нашему запросу Microsoft выдала HotFix, который должен быть установлен на компьютер
с серверной частью. Данный HotFix вы найдете в папке с сервером мониторинга, файл
Q923028_global.zip. Установка данного HotFix-а может потребовать скачивания дополнительного ПО с сайта Microsoft.

[Гость]

Действительно, падает только там где NOD32.
А где Касперский - не падает.
Большое спасибо.

А всё-таки исходники сервера доступны или нет ?