Iconics Genesis64 и OPC UA
| Author |
Message |
|
Written on: 21. 12. 2014 [15:06]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
Роман, ведите себя цивилизованно и уважительно. Без криков со знаками !!! И давайте вместо выяснения кто умнее решать вопрос.
Я вовсе не обязан в рамках бесплатной ТП что-то выяснять вообще, о чём уже также говорил неоднократно!
Поэтому если Вы хотите "цивилизованной" из ваших слов ТП, то знаете, что для этого нужно делать.
"rxs5" wrote:
сервер закрывает подключения только по прямым командам закрытия от клиента;
Вы видели дамп?
Видел.
"rxs5" wrote:
Я считал, что после того, как расписал по номерам пакетов что и когда происходит, вопроса о порядке взаимодействия не возникнет.
Клиент Genesis64 запрос на удаление подписки делает. Что отвечает сервер?
Клиент Genesis64 запрос на закрытие сессии делает. Что отвечает сервер?
А их не возникает — у меня всё закрывается и удаляется.
"rxs5" wrote:
- для случаев внезапного исчезновения клиента или "забывания" им про ранние подключения есть KeepAlive время, которое Вы категарически не ставили;
Каким образом KeepAlive поможет серверу отвечать на запросы клиента?
Какой вопрос был первичный, может превышение лимитов подключений?
А последний раз, что поставить советовал или может ещё с самого начала начнем?
Learn, learn and learn better than work, work and work.
|
|
Written on: 21. 12. 2014 [15:12]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
У меня приходят. Так и я написал, что в случае UAexpert на запрос клиента сервер отвечает нормально и удаляет подписку, и закрывает сессию. В случае клиента Genesis64 запрос на сервер есть, ответа от сервера нет. В этом и суть предыдущего моего сообщения с примерами.
Если это некорректное поведение клиента, то не пойму в чем оно выражается. Клиент Genesis64 запросы от отключение делает, судя по дампу. Если можете указать в чем именно некорректность Genesis64 - сообщу разработчикам.
Опять, я этого не обязан и не могу делать для невоспроизводимых у меня проблем!
Включайте отладку модуля OPC-UA, добавляйте недостающие сообщения и разбирайтесь!
Learn, learn and learn better than work, work and work.
|
|
Written on: 21. 12. 2014 [15:16]
|
|
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
|
Я вовсе не обязан в рамках бесплатной ТП что-то выяснять вообще, о чём уже также говорил неоднократно!
Поэтому если Вы хотите "цивилизованной" из ваших слов ТП, то знаете, что для этого нужно делать. Про ТП из того что мне известно: ваш партнер в России не спешил оформить необходимые бумаги, а Вы не сделали своему российскому партнеру необходимое пояснение, чтобы он не забыл про нас. И нам приходилось буквально напоминать вашему же партнеру, что желательно все оформить, но так и не закончилось ничем. Или не так?
Т.е. подводя итог, вы согласны, что при работе с клиентом Genesis64 сервер ведет себя некорректно (в части удаления подписок и закрытия сессий), но согласны этот вопрос исследовать только в рамках ТП. Все верно?
|
|
Written on: 21. 12. 2014 [16:18]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
По дампу, мои поиски (сервер .21, клиент .175)
1-е соединение
24 - открытие сессии 1
Создание.
"rxs5" wrote:
79 - создание подписки
608 - запрос клиента удалить подписку
612 - запрос клиента закрытие сессии 1
Так, забываем ещё быстрее?
Или ответы на Publish не насторожили, и что не понятного в 609, 613:
ServiceResult: 0x80250000 [BadSessionIdInvalid]
"rxs5" wrote:
2-е соединение
641 - открытие сессии
698 - создание подписки
1268 - запрос клиента на удаление подписки
1272 - запрос клиента на закрытие сессии 2
Что не понятно в 1269, 1277?
"rxs5" wrote:
3-е соединение
1297 - открытие сессии 3
1350 - создание подписки
1661 - запрос клиента на удаление подписки
1666 - запрос клиента на закрытие сессии 3
Что не понятно в 1662, 1670?
Где запросы CloseSecureChannel в конце этих кривых запросов к отсутствующему сеансу?
"rxs5" wrote:
Про ТП из того что мне известно: ваш партнер в России не спешил оформить необходимые бумаги, а Вы не сделали своему российскому партнеру необходимое пояснение, чтобы он не забыл про нас. И нам приходилось буквально напоминать вашему же партнеру, что желательно все оформить, но так и не закончилось ничем. Или не так?
Тот кто хочет не создаёт бумажных проблем.
"rxs5" wrote:
Т.е. подводя итог, вы согласны, что при работе с клиентом Genesis64 сервер ведет себя некорректно (в части удаления подписок и закрытия сессий), но согласны этот вопрос исследовать только в рамках ТП. Все верно?
По итогам — Вы забываете даже то, что обсуждалось в прошлой итерации и под проблемой клиента выставляете претензии к серверу!
Learn, learn and learn better than work, work and work.
|
|
Written on: 21. 12. 2014 [16:58]
|
|
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
|
От клиента Genesis64 идет запрос
UA Secure Conversation Message: DeleteSubscriptionsRequest
Сервер отвечает
UA Secure Conversation Message: ServiceFault с сообщением
ServiceResult: 0x80250000 [BadSessionIdInvalid]
И это при условии, на момент времени 609 пакета сессия была только одна и она вдруг стала IdInvalid
Или ответы на Publish не насторожили Насторожили, начиная с 111-го пакета. Почему сервер отвечает BadSessionIdInvalid мне непонятно, т.к. новая сессия не создавалась и активная только сессия, созданная на пакете 24.
Где запросы CloseSecureChannel в конце этих кривых запросов к отсутствующему сеансу?
Вот пример из UAExpert
"112","24.971146000","192.168.195.175","192.168.195.21","OpcUa","112","UA Secure Conversation Message: CloseSessionRequest"
"113","25.238082000","192.168.195.21","192.168.195.175","OpcUa","106","UA Secure Conversation Message: CloseSessionResponse"
"114","25.240828000","192.168.195.175","192.168.195.21","OpcUa","111","CloseSecureChannel message: CloseSecureChannelRequest"
Сначала идет закрытие сессии, потом уже CloseSecureChannelRequest от клиента.
Вот пример из Genesis64
"612","6.241505000","192.168.195.175","192.168.195.21","OpcUa","112","UA Secure Conversation Message: CloseSessionRequest"
"613","6.243019000","192.168.195.21","192.168.195.175","OpcUa","106","UA Secure Conversation Message: ServiceFault"
Нет от сервера ответа CloseSessionResponse, и клиент не делает запроса CloseSecureChannelRequest.
Зачем клиент Genesis64 должен делать запрос на закрытие CloseSecureChannelRequest, если сервер отвечает ServiceFault на предыдущий запрос?
И где ответы сервера на CloseSessionRequest после кривых ServiceFault (пользуясь вашими терминами) в ответе на Publish?
Тот кто хочет не создаёт бумажных проблем. либо альтернативный вариант - кто хочет, проходит процесс бумажных согласований, и не пускает дело на самотек. Ответ про ТП услышал.
[This article was edited 1 times, at last 21.12.2014 at 16:59.]
|
|
Written on: 21. 12. 2014 [17:01]
|
|
rxs5
Дмитрий Лыков
In tech support
Topic creator
registered since: 06.11.2013
Posts: 205
|
И еще один момент, упустил ранее, сейчас заметил.
Клиент Genesis64 на 107 пакете делает запрос
UA Secure Conversation Message: CreateMonitoredItemsResponse"
Но ответа от сервера не получает и далее делает еще запрос
UA Secure Conversation Message: PublishRequest
На который сервер отвечает
ServiceFault
Для сравнения с UAExpert
Клиент делает запрос
UA Secure Conversation Message: CreateMonitoredItemsRequest
И получает ответ от сервера
UA Secure Conversation Message: CreateMonitoredItemsResponse
Почему сервер OPC UA не ответил клиенту Genesis64 сообщением CreateMonitoredItemsResponse?
Во всех 3-х соединениях сервер OPC UA на запрос клиента Genesis64 с сообщением CreateMonitoredItemsRequest не отвечает аналогичным сообщением CreateMonitoredItemsResponse. И после этого уже идут ServiceFault.
Это просто в дополнение к предыдущему пояснению. Вопрос о ТП не отменяется.
|
|
Written on: 21. 12. 2014 [17:29]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"rxs5" wrote:
ServiceResult: 0x80250000 [BadSessionIdInvalid]
И это при условии, на момент времени 609 пакета сессия была только одна и она вдруг стала IdInvalid
Не вдруг, а на переподключении в 168, где он открыл новый канал и не создал новый сеанс или переподключился к существующему с помощью ActivateSession, смотрим спецификацию Part4, 5.6.2.1.
"rxs5" wrote:
Или ответы на Publish не насторожили Насторожили, начиная с 111-го пакета. Почему сервер отвечает BadSessionIdInvalid мне непонятно, т.к. новая сессия не создавалась и активная только сессия, созданная на пакете 24.
Выше!
"rxs5" wrote:
Где запросы CloseSecureChannel в конце этих кривых запросов к отсутствующему сеансу?
Вот пример из UAExpert
"112","24.971146000","192.168.195.175","192.168.195.21","OpcUa","112","UA Secure Conversation Message: CloseSessionRequest"
"113","25.238082000","192.168.195.21","192.168.195.175","OpcUa","106","UA Secure Conversation Message: CloseSessionResponse"
"114","25.240828000","192.168.195.175","192.168.195.21","OpcUa","111","CloseSecureChannel message: CloseSecureChannelRequest"
Сначала идет закрытие сессии, потом уже CloseSecureChannelRequest от клиента.
Может ссылаться таки на один файл?
"rxs5" wrote:
Вот пример из Genesis64
"612","6.241505000","192.168.195.175","192.168.195.21","OpcUa","112","UA Secure Conversation Message: CloseSessionRequest"
"613","6.243019000","192.168.195.21","192.168.195.175","OpcUa","106","UA Secure Conversation Message: ServiceFault"
Нет от сервера ответа CloseSessionResponse, и клиент не делает запроса CloseSecureChannelRequest.
Чего это он должен закрывать то чего у него, на этом канале, нет?
О чём и сообщает.
"rxs5" wrote:
И еще один момент, упустил ранее, сейчас заметил.
Клиент Genesis64 на 107 пакете делает запрос
UA Secure Conversation Message: CreateMonitoredItemsResponse"
Но ответа от сервера не получает и далее делает еще запрос
UA Secure Conversation Message: PublishRequest
А то, что ответов ServiceFault два (111, 113) ни о чём не говорит?
"rxs5" wrote:
Почему сервер OPC UA не ответил клиенту Genesis64 сообщением CreateMonitoredItemsResponse?
Всё по тому, что нет активного сеанса.
Learn, learn and learn better than work, work and work.
|
|
|
