algodevtrader
14 Aug 2019, 09:02

RE: RE:

algodevtrader said:

Panagiotis Charalampous said:

Hi Jeff,

I am 99% this has something to do with your QuickFix configuration. This is why we provide the dictionary. If after examining possible configuration issues you can still not figure out what is the problem, we can leverage to the product team for further investigation. However this is a time consuming process so let's rule out every other possibility.

Best Regards,

Panagiotis

Understood.  Will keep looking and report back to you what I find.  Thanks again for your help.

Hello Panagiotis,

I was able to fix this problem by switching to the non-SSL port for the broker.  Thanks for your help.

I have another issue, however.  There are some things I don't understand in your implementation of message type "V" for market data requests.  Below this message are the fields from a message you generated to subscribe to EURUSD in your sample program.

I understand that tag 262 was for a unique identifier.  The value you put was: EURUSD:WDqsoT  (which looks like an identifyer rather than a symbol so ok) but the value you put for tag 55 was "1".  I thought this should by the symbol name, that is, EURUSD or something similar.  The Spotware FIX dictionary says tag 55 ID's "Instrument identificators are provided by Spotware."  Can you please tell me where to find those and what should go in tag 262 as well.

Thanks again,

Jeff

-------------------------------------------

Tag Tag Description Value Value Description

8 BeginString FIX.4.4

9 BodyLength 150

35 MsgType V MARKET DATA REQUEST

49 SenderCompID pepperstone.3329145

56 TargetCompID cServer

57 TargetSubID QUOTE

50 SenderSubID 3329145

34 MsgSeqNum 2

52 SendingTime 20190814-02:55:08

262 MDReqID  EURUSD:WDqsoT

263 SubscriptionRequestType 1 SNAPSHOT PLUS UPDATES

264 MarketDepth 1

265 MDUpdateType 1 INCREMENTAL REFRESH

267 NoMDEntryTypes 2

269 MDEntryType 0 BID

269 MDEntryType 1 OFFER

146 NoRelatedSym 1

55 Symbol 1

10 CheckSum 052

algodevtrader
02 Aug 2019, 13:19

RE:

Panagiotis Charalampous said:

Hi Jeff,

I am 99% this has something to do with your QuickFix configuration. This is why we provide the dictionary. If after examining possible configuration issues you can still not figure out what is the problem, we can leverage to the product team for further investigation. However this is a time consuming process so let's rule out every other possibility.

Best Regards,

Panagiotis

Understood.  Will keep looking and report back to you what I find.  Thanks again for your help.

algodevtrader
02 Aug 2019, 12:15

RE:

Panagiotis Charalampous said:

Hi Jeff,

The github FIX API application was written by me and as you say it works. I was referring to the application you use. Based on the edited post it seems you are using QuickFix. Make sure that your QuickFix engine is using the dictionary posted above to validate messages. You can find more info on configuring QuickFix here.

Best Regards,

Panagiotis

Hi Panagiotis,

Ah, my apologies for not realizing it was your code and attributing you!  It really is a good and working piece of code and demonstrates the idea simply.  Yes, my code uses the QuickFix/n engine as I am writing in C#.  I will look again at the dictionary as you suggest.  However, I have been pouring over my configs and comparing my login message with the one you generate in your app and the fields appear to match now.  The one from your app connects and trades in my cTrader account at Pepperstone and my app does not although I can get the same code base working at other brokers so I know it generates working FIX messages.  Normally, when I need to debug these session/protocol level issues, there is someone at the other end (at the broker usually) that can tell me what they are seeing. With these smaller CFD brokers, I think that is not the case.  I think maybe some debugging advice with respect to cTrader may be helpful if I can find it.  Thanks for having this dialog with me.

Best Regards,

Jeff

algodevtrader
02 Aug 2019, 11:37

RE:

Panagiotis Charalampous said:

Hi Jeff,

Unfortunately I cannot advise you about an application I don't know about. Did you try contacting the developer of this third party application?

Best Regards,

Panagiotis

Hi Panagiotis,

Actually the 3rd party app works.  It's the sample on github that someone wrote that generates simple logons and orders etc.  I'm trying to make my app that I have working for other brokers do the same thing.  I edited my original message above with more information.  Basically, I am matching the logon message of a working app.  That's why I'm a bit confused.  If you have any other idea that I can try, it would be greatly appreciated.  The code I am using, I have working with 4 other brokers including 2 large institutional ones.  Again, any help appreciated.

Best,

Jeff

algodevtrader
02 Aug 2019, 10:54

RE:

Panagiotis Charalampous said:

Hi algodevtrader,

Does your application send heartbeats to keep the connection alive? You might also want to have a look at our FIX API dictionary in case your application uses it.

Best Regards,

Panagiotis

Hi Panagiotis and thanks for the quick reply.  Yes I always set up my FIX connections with heartbeats....usually 30 seconds.  In this case, everytime it times out and re-tries, it gets the same message.

I have a fair amount of FIX experience and my instinct tells me to try and make my login message look exactly like the one that is working in the sample code that I downloaded from github. (I just edited this message).   I am able to make my version of the logon message look almost identical to the one from the same code that works (from github) with the exception of the CheckSum, MessageLength and the SendingTime (which is different and would likely account for the other 2 differences)

The first message is from my app.  The second one if from the sample app that works.

8=FIX.4.4
9=128
35=A
34=64
49=pepperstone.3329145
50=3329145
52=20190802-08:28:31.371
56=cServer
57=TRADE
98=0
108=30
553=3329145
554=******
10=041

8=FIX.4.4
9=123
35=A
49=pepperstone.3329145
56=cServer
57=TRADE
50=3329145
34=1
52=20190802-02:14:59
98=0
108=30
553=3329145
554=******
10=033

Here's the output from the cTrader FIX server which appears every 30 seconds.

FIX: (OnCreate) FIX.4.4:pepperstone.3329145/3329145->cServer/TRADE
<event> Created session
<event> Connecting to 47.74.69.3 on port 5212
<event> Connection succeeded
<outgoing> 8=FIX.4.4
9=128
35=A
34=54
49=pepperstone.3329145
50=3329145
52=20190802-08:23:30.053
56=cServer
57=TRADE
98=0
108=30
553=3329145
554=*****
10=031

<event> Initiated logon request
<event> Session FIX.4.4:pepperstone.3329145/3329145->cServer/TRADE disconnecting: System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
   at QuickFix.SocketInitiatorThread.ReadSome(Byte[] buffer, Int32 timeoutMilliseconds)
   at QuickFix.SocketInitiatorThread.Read()
FIX: (OnLogout)

Thanks,

Jeff

algodevtrader
02 Aug 2019, 05:07

An existing connection was forcibly closed by the remote host.

Hello Panagiotis,

I am having the same problem as netread2004.  I am able to successfully log in for both feed and execution at Pepperstone using the cTrader sample API I downloaded from github and using the credentials provided to me by cTrader.  It then successfully is able to get both market data and send orders which show up on my demo account on cTrader.  However, using the same credentials in a FIX program that I successfully use at other (non-cTrader) brokers, I get the same "An existing connection was forcibly closed by the remote host." when I try to open the feed connection after the exec connection seems to connect.  Can you help me with this?  If so, please state what information you may required.

Thanks,

Jeff