#EOL
09 May 2017, 12:19

works good to me.

Can you double check that your password is correct?

Incorrect password is the only case I faced with dropping connection with no response

#EOL
24 Apr 2017, 11:20

Sinse you can see in cTrader all the trades made via FIX and vice versa, I think all the trades are processing in the same kind in the same place. As for me, the only advantage of using FIX instead of cAlgo is that it could be done without any graphical UI, thus, consume less VPS resources.

Regarding the quotes: it's still the same platform and the same trading account, so you will get the same spots and standard DoM quotes

Regarding "Spot Market Data Request": you can send only one Market Data Request per symbol. Once you sent it you will begin to receive realtime spot quotes and all the next subscription requests will be rejected. If there is any restrictions on the request frequency you need to use another button to find it

Regarding multiple connections: I was able to make aroud 10 simultaneous connection for a single account. If there is a limitation, it's greater than 10

#EOL
18 Apr 2017, 11:37

RE:

matnet70 said:

Hi i send Logon to Trade and Quote, send market data request snapshot and dont recive any prince 

When i send i recive only:

8=FIX.4.4
9=91
35=2
34=2
49=CSERVER
50=QUOTE
52=20170413-18:01:14.709
56=fxpro.xxxxx
57=QUOTE
7=2
16=0
10=199

check consistency of the sequence number

#EOL
18 Apr 2017, 11:16

Well, it's not exactly what happend.

Both messages you mentioned were sent by your application. Take a look: they both have SenderCompID=fxpig.xxxx and TargetCompID=cServer.

In fact between these to messages there should be a response from the server. Something like this:

8=FIX.4.4|9=188|35=j|34=12|49=CSERVER|50=TRADE|52=20170418-07:34:19.493|56=xxxx|58=INVALID_REQUEST:Order price = 1.006005 has more digits than symbol allows. Allowed 5 digits|379=1163558011|380=0|10=151|

And your application treated this message as invalid, because it does not contain tag 371, that could not be there according to the spec

If you are using QuickFIX, check out the dictionary for BusinessMessageReject message

And turn on incoming FIX logs at least for trading connection, this will help you to investigate issues in the future

#EOL
07 Apr 2017, 10:39

It should be two different config files and two different instances of quickfix.Application interface

#EOL
06 Apr 2017, 13:05

RE: RE: RE: RE: RE: RE: RE: RE: RE: RE:

Well, I know what json is and I whould like to assure you that there is nothing related to JSON in the example application, because it uses FIX protocol that was invented much much earlier

Related to the example -- i repeat, it's an exmple software, not a production-ready solution. In some cases it works, in some -- it does not. If you don't have certain skills in concurent software development, probably this is not your way.

#EOL
06 Apr 2017, 11:04

RE: RE: RE: RE: RE: RE: RE: RE:

mindbreaker said:

But sometimes show  one positions sometimes 2 or somtimes all positions.

Is should return json string with all positions. Thats it.

I don't understand what json you talk about.

FIX is not json and json is never mentioned in your code.

If you have any doubts about the server -- check first with MiniFIX and if it works with it, it's not server fault, but your application

#EOL
05 Apr 2017, 14:28

RE: RE: RE: RE: RE: RE:

mindbreaker said:

Hi i've got 727=4

And in my example buffer is 4096 but it send what want (why this does not display positions in json format !!!!!!????).

Ok it doesn't matter.

Thanks for the help.

Do you receive 4 position reports? Can you put a breakpoint to see the buffer? How many positions do you acually have and see in cTreader/cTrader Web?

Buffer size does not matter if the reports have not received yet. From my point of view, it should be separate thread that reads the stream, separates business messages (like execution reports, position reports, etc) from connection messages (like logon, heartbeats, test requests), stores the first ones to queue, raise specific events and maintains connection messages by itself. But implementing such framework would be re-inventing QuickFIX or similar engine.

#EOL
05 Apr 2017, 12:46

RE: RE: RE: RE:

mindbreaker said:

Then why sometimes send all positions? It is server error!

I show everything from stream with MessageBox.Show()

I test it on two different servers and two different visual studio (2012 and 2010)

(i just download example from FIX-API-sample without changes)

Have you worked with FIX before?

Have you tried any third-party FIX clients other than FIX-API-sample or homebrew clients based on FIX-API-sample? (For example MiniFIX?)

Could you provide any FIX logs?

What do you have in tag 727 in the report?

How many positions do you expect?

When you receive your position partially, are all the FIX messages complete? (end with |10=[checksum])

        private string SendMessage(string message, SslStream stream, bool readResponse = true)
        {
            var byteArray = Encoding.ASCII.GetBytes(message);
            stream.Write(byteArray, 0, byteArray.Length);
            var buffer = new byte[1024];
            if (readResponse)
            {
                Thread.Sleep(100);
                stream.Read(buffer, 0, 1024);
            }
            _messageSequenceNumber++;
            var returnMessage = Encoding.ASCII.GetString(buffer);
            return returnMessage;
        }

I'm not a developer, but this looks ugly to me. Meaning that size of average FIX position report is 200 bytes, only 5.12 reports will be shown and I have no idea what will happen with the other. And this is true only in ideal zero-latency world, since it waits only for 100 ms from sending the request. What is you round-trip round-trip delay time to the server?

So I would not be trust to FIX-API-sample. It's a sample, not a production-ready solution.

#EOL
03 Apr 2017, 17:42

RE: RE:

mindbreaker said:

 

When I send a query again I never get all opened positions.!

Something is wrong with this server.

Just opened 1990 positions and got them all on the Request for positions. If there is an error it's not in the server.

You may want to refer TotalNumPosReports (tag 727) from the first position report to get know how many reports to expect

#EOL
30 Mar 2017, 17:55

Have you tried your code with Spotware account? I can't connect to h20.p.ctrader.com:5211 neither, maybe the problem is only with this one server.

#EOL
27 Mar 2017, 16:42

that's a...

OK, I don't understand why everybody is trying to maintain the protocol by themselves instead of taking some ready FIX engine framework like QuickFIX.

you do realise, that you will have to process all the heartbeats and test requests by your own code, don't you?

particulary your code uses different set of SenderCompID, SenderSubID, TargetCompID and TargetSubID parameters in logon message and spot subscription.

And it seems, that it calculates incorrect checksums that could be a reason why server ignores them: https://goo.gl/y5KAkn

#EOL
27 Mar 2017, 10:00

Hey taskman9

According to Spotware FIX specification you can't subscribe to only bid or only ask spot events, so the part |267=2|269=0|269=1| is compulsory for spot subscription request, while your requests are not correct from protocol point of view: field NoMDEntryTypes (tag 267) [that means "number of market data entry types"] is set to 2, but it is followed by only one MDEntryType (tag 269) field

#EOL
22 Mar 2017, 11:26 ( Updated at: 21 Dec 2023, 09:20 )

RE:

Spotware said:

You are advised to use the host name rather than the IP since the IP might change from time to time.

What hostname are you talking about?

#EOL
22 Mar 2017, 10:36

RE: RE:

dm.skpd said:

On a side note: nothing was changed for rest brokers, I still can't Logon on 5202 port for brokers: pepperstone, icmarkets, fxpro.

The only version I have, is that different servers are used for demo an live accounts. So you should check connections settings in cTrader for the exact account you are going to use via FIX.

And, probably, you may want to change your password for accounts fxpig.3000369 and fxpig.3000367, since they are exposed in the FIX logs you posted earlier (tag 554)

#EOL
21 Mar 2017, 14:56

You are sending orders to market data connection. Try trade one, it's on the different port and TargetSubID (tag 57) = TRADE

#EOL
20 Mar 2017, 10:40

That's strange. This log works for me and I don't see any major difference comparing with yours.

< 8=FIX.4.4|9=115|35=A|49=pepperstone.3185673|56=CSERVER|34=1|52=20170320-08:10:50|57=QUOTE|141=Y|108=30|98=0|553=3185673|554=sqR0de|10=134|
> 8=FIX.4.4|9=96|35=A|34=1|49=CSERVER|50=QUOTE|52=20170320-08:10:50.125|56=pepperstone.3185673|98=0|108=30|141=Y|10=198|

What host and port do you use?

#EOL
13 Mar 2017, 15:49

RE:

j.tarno said:

I am sending a logon:

8=FIX.4.4|9=112|35=A|34=1|49=pepperstone.XXX|50=QUOTE|52=20170310-15:13:10.949|56=cServer|98=0|108=0|553=XXX|554=XXX|10=156

Hi Jan

You should set field TargetSubID (tag 57) to QUOTE for your outgoint FIX messages and set SenderSubID (tag 50) to any string you want or don't set it at all.

From the other hand, server will respond you with FIX messages with QUOTE in SenderSubID (tag 50), so, don't be confused with this, take a look on Exaples section (chapter 5) of the specification: https://www.spotware.com/pdf/cTraderFixApi_v2.9.1.pdf?v2.9.1

Good luck

#EOL
20 Feb 2017, 14:02

RE:

#EOL said:

Hi there. 

Take a look on this log that works for me: https://goo.gl/oOrnpT

I think the problem with yours one is tag misordering.

I bet MDEntryType (tag 269) records shold be strictly after NoMDEntryTypes (tag 267)

http://www.onixs.biz/fix-dictionary/4.4/msgType_V_86.html#Strucutre

#EOL
20 Feb 2017, 13:59

Hi there. 

Take a look on this log that works for me: https://goo.gl/oOrnpT

I think the problem with yours one is tag misordering.

I bet MDEntryType (tag 269) records shold be strictly after NoMDEntryTypes (tag 267)