Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Новый топик    Ответить
 Прием передача сообщений по TCP/IP  [new]
Бакланов Сергей
Member

Откуда:
Сообщений: 16
Поставлена задача организовать прием передачу сообщений по TCP/IP между серверами.
На начальном этапе имеем две программы. Одна это сервер другая клиент. Серверная программа открывает порт: dev:(:port:"CT"):1 '$t w "<error>",! q
и слушает: dev f  r data:1 i $t q:data="<STOP>"  u $p w data,! dev

Клиентская программа открывает порт: dev:(ip:port:"CT"):10 t=$t i '$t w "<error>",! q
и посылает на сервер сообщения: dev  n=1:1:max Message(n),!

Обнаружилась следующая проблема: Если серверная и клиентская машина находятся в одной сети, все работает. Если в разных сетях, не работает. На клиентской машине не открывается порт: dev:(ip:port:"CT"):10

Подскажите, в чем тут дело ?
26 дек 14, 09:11    [17055026]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
П.С.М.
Member

Откуда: Из СССР
Сообщений: 453
Бакланов Сергей
Если в разных сетях, не работает.

А машины то видны друг другу в этих разных сетях? Пинг идет между ними? А то может быть тут вопрос и к каше то не относится, а скорее к конфигурированию сети.
26 дек 14, 09:32    [17055139]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
Бакланов Сергей
Member

Откуда:
Сообщений: 16
PING есть
26 дек 14, 09:47    [17055231]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
Бакланов Сергей
Member

Откуда:
Сообщений: 16
PING проверил только с клиентской машины. С серверной не знаю
26 дек 14, 09:50    [17055257]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow
Сообщений: 2633
Ну если внутри одной сети все работает, а в разных сетях нет, то тут разумно проверять маршрутизацию трафика между этими сетями, и все брандмауэры. Скорее всего где то закрыт доступ по вашему порту
26 дек 14, 09:59    [17055315]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
Бакланов Сергей
Member

Откуда:
Сообщений: 16
Да, дело оказалось в брандмауэре на серверной машине.
Спасибо
26 дек 14, 11:29    [17055936]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3117
Блог
Бакланов Сергей,

С сокетами можно работать и по-другому.
30 дек 14, 10:22    [17071183]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
eduard93
Member

Откуда:
Сообщений: 167
servit,

Или встроенный %CSP.WebSocket использовать.
30 дек 14, 18:37    [17074194]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3117
Блог
eduard93,

Вебсокеты - это "несколько" другое.
Тогда ТС придётся использовать ещё и веб-сервер в своей схеме общения между серверами, настраивать веб-сервер, CSP-Шлюз и т.п.
31 дек 14, 09:10    [17075760]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Прием передача сообщений по TCP/IP  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 810
Напишу тут, чтобы не плодить темы...

Одно и то же ПО (Обмен по TCP-сокету) установлено на машинах, находящихся в пределах внутренней и внешней сети.
Тестирую обмен короткими пакетами, отрабатываю различные команды, измеряю время отклика. Обмен происходит каждые 5 минут (288 сеансов в сутки). Время отклика во внутренней сети составляет примерно 50 мс(плюс-минус влияние моделируемой нагрузки на сервер Каше), во внешней сети (разные города) - примерно 100..120..140 мс(тоже с учетом влияния нагрузки). Соединение непостоянное, после окончания сеанса TCP-порты закрываются. Проверяю и набираю статистику времени отклика, в зависимости от графика суточной загрузки сети, суточной (предполагаемой) нагрузки на серверах Каше (моделирую нагрузку). В целом получаю картину, удовлетворяющую поставленным требованиям.
Но!!!
При обмене между серверами во внешней сети наблюдаю всплески задержки с устойчивым временем 3 секунды. Их количество колеблется от 5..10 до 15..20 в сутки. Во время нагрузки на канал связи всплески появляются чаще, во время небольшой нагрузки на канал связи их может не быть часами.

Вопрос: что это могут быть за 3 секунды, можно ли на них повлиять как-то, путем настроек..?

Кто сталкивался с подобным - поделитесь мыслями, соображениями, опытом...

Заранее благодарен.
12 июл 16, 16:08    [19400609]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 810
Да, забыл сказать, я пытался найти в интернете что-нибудь по поводу этих 3 секунд, но так и не нашел ничего внятного...
12 июл 16, 16:44    [19400817]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow
Сообщений: 2633
AlexKB
Во время нагрузки на канал связи всплески появляются чаще, во время небольшой нагрузки на канал связи их может не быть часами.
А не могут ли это быть проблемами сетевого стека, все от драйверов до железа ? В таком случае имеет смысл попробовать что-то поменять, и такие проблемы как я понимаю тоже могут быть смоделированы.
12 июл 16, 16:47    [19400831]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 810
DAiMor,
По моим, правда субъективным, оценкам пики задержек возникают где-то на уровне транспорта за пределами офиса. Внутри офиса таких задержек с таким устойчивым временем 3 сек не возникает. Бывают спонтанные задержки, зависимые от нагрузки сервера, с которым ведется общение. Мои предположения, что где-то на уровне провайдеров, сетевого канального оборудования, всего того, чем я не владею...
Тут весь вопрос в том, сталкивался ли кто-нибудь с подобным? Есть ли способы устранить, или уменьшить такое влияние? Удалось ли это сделать?
Само по себе проявление таких задержек не является критичным, но является неприятным, поскольку не прогнозируемо.
Ну и вытекающие отсюда последствия локализации такого проявления, последующего анализа, т.п.

Тестирование проводится на временно предоставленным мне машинам (около 20), и я это наблюдаю только если связь происходит между абонентами, не находящимися в пределах одного офиса. Скоро машины заберут и я не смогу больше экспериментировать, к сожалению...
13 июл 16, 08:12    [19402647]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno -> Moscow
Сообщений: 2633
AlexKB,

Насколько я понимаю, в данном случае, единственно что может как то влиять это изменение размера MTU
13 июл 16, 10:10    [19402998]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1547
AlexKB
где-то на уровне провайдеров, сетевого канального оборудования, всего того, чем я не владею...
Наблюдал, как этим занимаются специалисты, и немного занимался этим сам.
Надо искать узкое место - слабое звено. Меня бы встревожил уже ping > 100ms (в нашей системе ping > 50ms недопустим, хорошим значением считается 25ms).
Для моделирования трафика есть специальные утилиты (e.g. iperf), но часто применяют простейшие приёмы:
1)
a. ping -t <тот конец>
b. ping -t <какой-нибудь популярный и-нет ресурс, который должен отвечать быстро>
если большая разница между a и b, <подозрение на провайдера на том конце> либо <на том конце что-то не так настроено>;
если a и b одинаково плохо, <подозрение на провайдера на нашем конце> либо <на нашем конце что-то не так настроено>.

2) Далее можно искать, какое именно звено тормозит, если неясно, в сети какого провайдера проблема. Утилиты: pathping (windows), nmap (linux).

Такая вот муторная работа. Задержки скорее всего на стадии установления соединения: 3 минуты > всех разумных tcp-таймаутов, вы скорее всего делаете повторные попытки установления соединения на прикладном уровне. Установление соединения - вообще самая уязвимая операция, вспомните, как часто при плохом и-нете приходится жать на Ctrl-F5 в браузере. Понимаю, что софт править нелегко, но если перейти на постоянные сеансы, ситуация с задержками может улучшиться.
13 июл 16, 11:59    [19403617]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 810
Alexey Maslov,
Задержка отклика не 3 минуты, а 3 секунды+штатная задержка отклика. Пинг в основном на уровне 40 и меньше мсек (бывают правда всплески..., но редко). Определение стороны проблем по пингу да, я так примерно и делаю(вручную). Но я не могу таким образом определить на прикладном уровне, где возникают эти три секунды. Всплески одиночные, даже на одном провайдере, по одному общему направлению на другой город, где в одном офисе стоят два удаленных сервера, один отклик будет с задержкой, а второй нет.
Мне просто непонятно, почему стабильно 3 секунды присутствуют в таких всплесках.
13 июл 16, 13:30    [19404117]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
AlexKB
Member

Откуда: Запорожье
Сообщений: 810
Время пинга определяю таким образом:
set tPing1=$zh
set 
restTestTCP=##class(%SYSTEM.INetInfo).CheckAddressExist(IPaddress)
set timePing=$zh-tPing1*1000
13 июл 16, 13:34    [19404145]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1547
AlexKB,

извини, ошибся с 3 минутами :)
Тестируя сетку, лучше действовать на уровне утилит ОС.
Даже простенький непрерывный 'ping -t ip-address' позволяет собрать статистику по потерям пакетов и колебаниям времени ответа (в Cache это, конечно, можно заскриптовать, но смысл?)

tracert | pathping | nmap могут помочь найти тормозящую сеть/хост.
13 июл 16, 16:01    [19404998]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3117
Блог
Alexey Maslov
Тестируя сетку, лучше действовать на уровне утилит ОС.
Что метод CheckAddressExist и делает.
AlexKB
Вопрос: что это могут быть за 3 секунды, можно ли на них повлиять как-то, путем настроек..?
Это могут быть константы жёстко вшитые в код (типа hang 3), как например:
quit $zf(-1,"ping -w 1000 -n 1 "...
в указанном Вами CheckAddressExist или настройки ОС.
AlexKB
Вопрос: можно ли на них повлиять как-то, путем настроек..?
Хороший вопрос для WRC.
Попробуйте поиграться с:
PS: вместо open/use/close посмотрите в сторону их объектных аналогов: так будет больше контроля за открытием/закрытием соединений, обработкой ошибок, callback-и и т.д.
13 июл 16, 16:09    [19405046]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1547
servit,

у каждого конечно свой опыт, но:

servit
Что метод CheckAddressExist и делает
Он совсем другое делает: шлёт всего один пакет (-n 1), я же предложил непрерывный ping; добавлю к этому, что на длительное время (на 1 час как минимум).

servit
Это могут быть константы жёстко вшитые в код
В код вшито '-w 1000' - этого всего лишь время ожидания ответа (в мс), а не принудительная задержка. Как вы, конечно, знаете, ping работает не по tcp, а по icmp, поэтому время ожидания надо задавать явно.

AlexKB, а вот случайно и про 3 сек нашёл:
Microsoft TechNet. Appendix A: TCP/IP Configuration Parameters
TcpInitialRTT
Key: Tcpip\Parameters\Interfaces\interfaceGUID
Value Type: REG_DWORD—number
Valid Range: 0–0xFFFF
Default: 3
Description: This parameter controls the initial time-out in seconds used for a TCP connection request and initial data retransmission on a per-interface basis. Use caution when tuning with this parameter because exponential backoff is used. Setting this value to larger than 3 results in much longer time-outs to nonexistent addresses


Возможно, совпадение, но подтверждает начальное предположение, что проблема возникает при установлении соединения.
13 июл 16, 16:33    [19405172]     Ответить | Цитировать Сообщить модератору
 Re: Прием передача сообщений по TCP/IP  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3117
Блог
Alexey Maslov
servit
Это могут быть константы жёстко вшитые в код
В код вшито '-w 1000' - этого всего лишь время ожидания ответа (в мс), а не принудительная задержка. Как вы, конечно, знаете, ping работает не по tcp, а по icmp, поэтому время ожидания надо задавать явно.
Это был всего лишь пример того, как в код по-разному могут быть вшиты константы, и совершенно не относящийся к проблеме ТС.
Жаль, что построенная мною фраза вызвала недопонимание.
13 июл 16, 16:45    [19405237]     Ответить | Цитировать Сообщить модератору
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Ответить