How to tell FIX acceptor not to send messages if 43=Y
or if that is not possible to be done from client side...
How to tell my initiator app to ignore incoming messages if 43=Y
QuickFixN version 1.5.0
I think you're saying that your app is the Initiator, and it is connecting to someone else's Acceptor, right? (Please correct me if I'm mistaken.)
In that situation, you can't really tell the Acceptor how to behave. It's outside of your control.
What you can do, is inside your OnMessage(ExecutionReport) function, just wrap your behavior in
if(msg.Header.IsSetField(43) && msg.GetString(43)=="Y") {
...
}
Related
I'm trying to build a entirely contained trading simulator using quickfix/J. The systems ought to consist of 2 client applications (a market/exchange and a broker) as well as a router (server/acceptor). In particular I'd like to know:
Client-Client communication
How the two clients can communicate to each other, but the server handling all the messaging logic, ie. messages should go through server and it should decide where and how to forward messages. I ought to be able to pass a targetID in FIX message, and the server app should handle routing to desired client.
Multiple clients on same port
Have multiple clients connected on same port but messages should only go to a particular sender comp Id ie. clients should not be privy of communication from other clients.
I've already set up the acceptor, and 2 clients. I know I could do this programmaticaly using plain old Java but I'd like to leverage the quickfix library and would like a relativly out of the box solution.
MVP: client (broker) sends fix message through the acceptor(router), message is processed and forwarded to a particular market, market recieves message through server and does some business logic, market sends fix message back to client through acceptor.
ps: I like the quickfix library but I'm very flexible if there any other library/languages you'd recommend
Short answer: QuickFIX/J (as far as I can tell similarly QuickFIX or quickfix/n) will not route messages based on tags. This has to be implemented in your application code.
Edit: with regard to your second point. There is no problem having your FIX server listening for multiple FIX connections on the same port (This applies for QuickFIX/J and I guess also the other language variants.) Sessions are addressed via the SessionID so it is ensured that only the correct FIX Session gets its messages.
Our system generates some messages (unsolicited cancel for example) it needs to send to the other party after a disconnect/connection lost, as soon as the connection recovers.
The problem is that we trigger sending those in onLogon(), but if there's a Resend Request that's too early and we had problems (maybe just because of how is implemented on the other end) when we had too many messages to send (hundreds).
I'm aware that ResendRequest may not come and it is impossible to figure that out without simply waiting, but what would be the best approach for us using QuickFIX/J to send our messages as soon as possible but after sequence numbers are synchronized?
EDIT: I'm trying to solve this using FIX 4.2. FIX 4.4 actually introduced http://www.onixs.biz/fix-dictionary/4.4/tagNum_789.html which would solve my problem (as long as the other party sends this optional tag too).
Thanks
My 10 cents is it sounds like you're trying to treat 2 scenarios in 1 go, and that's difficult. Do 1 thing at a time. For example, if it's your network that causes you to disconnect, before your client knows you've disconnected, your clients will send resend requests, right? Meanwhile, if a client disconnects but you don't then when they reconnect you gap fill. You've got to look carefully at the scenarios. Yes, a resend request may not come at all, it all depends how the client configures things their side. Maybe, per this question you want to send sequence resets because actually, the messages you're trying to send are quotes, right? I mean, what kind of messages are you trying to resend after a disco?
In the documentation for chrome.sockets.tcpServer and chrome.sockets.tcp there is nowhere mentioned how to listen to disconnection of clients. How can I do it?
I found out that you get a resultCode == -15 in the callback of the chrome.sockets.tcp.send-function if the client was disconnected. But I really want to get notified if someone disconnects instead of use only the pro-active method of checking that.
It's my understanding that socket disconnection isn't something the underlying OS can detect. There's no socket-level way to tell the difference between a client that is gone and a client that might simply be taking a while to send the next packet. It's possible someone with deeper TCP/IP knowledge will correct me, but this is always the answer I've seen.
You can have clients send an application-level disconnect message, or else a periodic heartbeat without which the server will conclude the client is gone. More detail here: Is TCP Keepalive the only mechanism to determine a broken link?
I thought chrome.sockets gave you an onReceived event with byteLength 0 packet which means they disconnect, right? I mean that's how I would gracefully disconnect, send a payload with 0 bytes.
Recently, i found my application, which's developped under Delphi.NET, the socket callback function never get called, causing the socket message cannot be sent to the target client.
Is it possible a bug of the socket class in Delphi.NET? Or will it be relative to the Anti Virus software, or something else? Since this problem only happen in some workstation, but not all my testing environment.
Thank you.
Finally, i've got the answer, it's just because .NET Framework 1.1 hasn't been installed in the workstation, once installed, all goes fine
You're highly likely sending it to the wrong endpoint. Make sure your socket is connected before sending messages.
Until we see some code we're unable to help you any further.
I'm trying to replace some bespoke message queues with ActiveMQ, and I need to talk to them (a lot) from Perl. ActiveMQ provides a Stomp interface and Perl has Net::Stomp, so this seems like it should be fine, but it's not.
Even if I send a BEGIN frame over Stomp the messages sent with SEND are immediately published, and if I ABORT the transaction nothing happens.
I can't find any clear answers suggesting that it's not possible, that it is possible, or that there's a relevant bit of configuration. Also, Stomp doesn't seem to be a great protocol for checking for error responses from the server.
Am I out of luck?
BTW the best place to ask Perl/ActiveMQ/Stomp questions is the ActiveMQ user forum as lots of Perl-Stomp folks hang out there.
The trick with STOMP transactions is to make sure each message you send or each acknowledgement you make includes the transaction ID header. See the transaction handling section of the STOMP protocol.
The reason for this is that with STOMP you could have many transactions taking place at the same time if your client is multi threaded - along with some non-transacted operations.
Have a look at Net::Stomp::Receipt. It's a subclass of Net::Stomp that implements "return receipts" from the Stomp protocol, and allow you to make sure the correct reception of your message, and abort the transaction otherwise.
You have to wrap the acknowledgements inside a transaction.
In pseudocode (or pseudo STOMP) this would be:
BEGIN [TRANSACTION-ID] -> send to server
MESSAGE [MESSAGE-ID] (received) <- received from server
ACK [MESSAGE-ID] [TRANSACTION-ID] -> send to server
COMMIT [TRANSACTION-ID] -> send to server
I have already gotten this working with the PHP driver (patching the abort call to use the transaction ID when I pass in a frame object to acknowledge).
Unfortunately, after redelivering four messages the client stops. At least this happens to me.