QuickFIX/n - Инициатор неоднократно бросает ошибки во время фазы входа

Question

Я использую торговое клиентское приложение по этой ссылке ниже, чтобы установить соединение между одним из серверов 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, я действительно не могу понять, что пошло не так. Одна из возможных областей расследования, о которых я могу думать, это то, что мой сертификат stunnel может быть недействительным, поскольку я также очень новичок в программе stunnel (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 после того, как установил debug verbose high, принимая предложение от 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-адрес и номер порта Borker на 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 

Answer 1

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

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

Если это невозможно, вам нужно будет поэкспериментировать с тем, что может быть неправильным. По моему опыту, проблема часто является несоответствием в порядковых номерах (тег 34). Большинство серверов будут поддерживать последний порядковый номер, который вы отправили (скажем, 1), и после отключения будет ожидать, что вы отправите свое сообщение в Logon со следующим номером (2 в этом примере). Попробуйте начать с 1 и увеличивать количество секунд между повторными соединениями.

Другая возможная проблема - неправильные идентификаторы CompID (Sender или Targer).

UPDATE (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 прослушивает).