c # — QuickFIX / n — инициатор многократно выдает ошибки во время фазы входа
Я использую приложение торгового клиента по этой ссылке ниже, чтобы установить соединение между одним из моих VPS-серверов и брокерским сервером.
http://www.quickfixn.org/tutorial/example-applications .
После одной недели борьбы я смог, наконец, свободно подключиться к серверу брокера.
Однако, когда я запускаю торговое клиентское приложение, на этапе входа в систему я получаю следующие ошибки:
Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host
at QuickFix.SocketInitiatorThread.ReadSome(Byte[] buffer, Int32 timeoutMilliseconds)
in ... SoecketInitiatorThread.cs:line 170 ......
at QuickFix.SocketInitiatorThread.Read() in ... SoecketInitiatorThread.cs:line 80
......
Приложение торгового клиента продолжает повторять попытку входа в систему, однако продолжает получать только одно и то же сообщение об ошибке.
Конечно, с таким новичком, как я, на этом движке QuickFix / n, я действительно не могу понять, что пошло не так. Одна из возможных областей исследования, о которой я могу подумать, заключается в том, что мой сертификат о защите от ошибок может быть недействительным, так как я также новичок в программе для защиты от вирусов (https://www.stunnel.org). Я только следовал инструкциям с веб-сайта, чтобы настроить сертификат pem с IP-адресом брокера, но я не уверен на 100% о его назначении.
Вот что я положил в файл «stunnel.conf»:
[FIXORDER]
client = yes
accept = external ip of VPS : port eg.(10.160.103.65:22)
connect = broker ip address :port eg.(102.12.124.9:444)
Вот некоторая запись зарегистрированного сообщения от программы Stunnel:
2014.11.26 17:23:44 LOG5[3348]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2014.11.26 17:23:48 LOG5[760]: Service [FIXORDER] accepted connection from x.xx.xx.xxx:xx
2014.11.26 17:23:48 LOG5[760]: s_connect: connected xxx.x.xx.xxx:xxx
2014.11.26 17:23:48 LOG5[760]: Service [FIXORDER] connected remote server from x.xx.xxx.xxx:xxx
2014.11.26 17:23:48 LOG3[760]: SSL_connect: Peer suddenly disconnected
2014.11.26 17:23:48 LOG5[760]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
Я построил сертификат, используя вышеупомянутый файл «stunnel.conf», используя встроенное приложение для самостоятельной сертификации.
Как видите, для новичка, такого как я, это сложно, любые мысли или советы по этой проблеме будут по достоинству оценены.
Большое спасибо заранее.
С уважением.
M
================================================== ================================
Обновлено 27/11/2014
Здесь я обновляю свой журнал ошибок из файла журнала Stunnel после того, как я установил подробный отладочный максимум, принимая предложение от xapi1492.
2014.11.27 01:10:46 LOG7[944]: Service [FIXORDER] started
2014.11.27 01:10:46 LOG5[944]: Service [FIXORDER] accepted connection from x.xxx.xxx.xxx:3667
2014.11.27 01:10:46 LOG6[944]: s_connect: connecting xx.x.xx.xx:9002
2014.11.27 01:10:46 LOG7[944]: s_connect: s_poll_wait xx.x.xx.102:9002: waiting 10 seconds
2014.11.27 01:10:46 LOG5[944]: s_connect: connected xx.x.xx.xx:9002
2014.11.27 01:10:46 LOG5[944]: Service [FIXORDER] connected remote server from x.xxx.xxx.xxx:3668
2014.11.27 01:10:46 LOG7[944]: Remote socket (FD=392) initialized
2014.11.27 01:10:46 LOG6[944]: SNI: sending servername: xxx.x.xx.xx
2014.11.27 01:10:46 LOG7[944]: SSL state (connect): before/connect initialization
2014.11.27 01:10:46 LOG7[944]: SSL state (connect): SSLv2/v3 write client hello A
2014.11.27 01:10:46 LOG3[944]: SSL_connect: Peer suddenly disconnected
2014.11.27 01:10:46 LOG5[944]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
2014.11.27 01:10:46 LOG7[944]: Remote socket (FD=392) closed
2014.11.27 01:10:46 LOG7[944]: Local socket (FD=380) closed
2014.11.27 01:10:46 LOG7[944]: Service [FIXORDER] finished (0 left)
================================================== ================================
Обновлено 28/11/2014
По-прежнему трудно найти ответ, поэтому я решил предоставить свой конфигурационный файл для клиентского приложения QuickFix.
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=store
FileLogPath=fixlog
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=Y
DataDictionary=FIX44.xml
SocketConnectHost= xxx //my vps ip address
SocketConnectPort= xxx //my vps port //specified on stunnel
ResetOnLogon=Y
ResetOnLogout=Y
ResetOnDisconnect=Y
CheckLatency=N
LogonTimeout=10# standard config elements
[SESSION]
BeginString=FIX.4.4
SenderCompID= xxx //my ID
Username= xxx //my username
Password= xxx //my password
TargetCompID=FIXORDER
HeartBtInt=30
SocketConnectHost= xxx //my vps ip address
SocketConnectPort= xxx //my vps port //specified on stunnel
DataDictionary=FIX44.xml
================================================== ================================
Обновлено 28/11/2014
Принимая предложение от xpa1492, я поместил IP-адрес Боркера и номер порта на SocketConnectHost
и SocketConnectPort. Вот сообщение журнала, которое я получаю из своего клиентского приложения QuickFix.
Кажется, что первоначальное соединение установлено, но, возможно, запрос на вход в систему как-то недействителен.
<event> connecting to xxx (ip address of broker);
<event> connection succeeded;
<event> session reset: ResetOnLogon;
<event> session reset ResetSetNumFlag;
<outgoing> 8=Fix4.4 ...... ;
<event> initiated logon request;
<incoming> 8=FIX4.4 .....;
<event> received logout request;
<outgoing> 8=FIX4.4 .....;
<event> sending logout response;
Подробности входящего сообщения от брокеров, когда они отправляют запрос на выход.
<incoming> 8=FIX4.4 9=63 35=5 34=1 49=FIXORDER 52=20141128-02:09:00.495 56=TargetCompID(from acceptor standing point of view=SenderID for me) 10=171
Решение
Для серверов FIX очень часто разрывать соединения, когда им что-то не нравится в вашем первом сообщении (которое всегда является сообщением о входе в систему). Исходя из полученной ошибки, это именно то, что происходит — вы подключаетесь к серверу, отправляете сообщение о входе в систему, а затем сервер прерывает соединение.
Правильный способ решения проблемы — обратиться в службу технической поддержки на другом конце и спросить их, почему они разрывают соединение.
Если это невозможно, вам нужно будет поэкспериментировать с тем, что может быть не так. По моему опыту, проблема часто заключается в несоответствии порядковых номеров (тег 34). Большинство серверов сохраняют последний отправленный вами порядковый номер (скажем, 1), и после отключения ожидается, что вы отправите свое сообщение о входе в систему со следующим номером (2 в этом примере). Попробуйте начать с 1 и увеличить число seq между повторными соединениями.
Другая возможная проблема — неправильные CompID (Отправитель или Targer).
ОБНОВЛЕНИЕ (настройка sTunnel и SSL-сертификата):
Возможно, что сервер разрывает соединение, потому что вы не подключаетесь через SSL … Файл stunnel.conf должен выглядеть так:
; Enable debug (7 is the most verbose output)
debug = 7
output = stunnel.log
[FIXORDER]
client = yes
accept = 127.0.0.1:[port number your client connects to]
connect = [fix server ip]:[fix server port]
cert = xxx_cert.pem
key = xxx_key.pem
Обратите внимание, что accept может быть 127.0.0.1 или IP вашего VPS-сервера, но 127.0.0.1 является предпочтительным выбором. Ваш клиент Fix также может просто подключиться к 127.0.0.1 (где слушает sTunnel).
Другие решения