For example I have config for QuickFix/n with several sessions. I have noticed that QuickFix/n sends Logon messages for these sessions in random order (but I am not sure of that).
Is it possible to set/configure a fixed order of Logon messages?
Update
I am integrating with a third-party FIX server. Their support said to me that I should send two Logon messages (for two sessions) in sequential order. Here is part of their message:
Please connect in the below order:
1. Logon to STREAMING (35=A)
2. Logon to TRADING (35=A)
3. Subscribe to XXX/YYY on the STREAMING session (35=V) - Only on the streaming, as the trading session is for Orders / Trades only.
So, looks like I should send Logon to STREAMING session in first order and then send Logon to TRADING session in second order.
Problem Solved
The support team of third-party FIX server sent a message where they said that Logon messages should be send simultaneously. So, my decision (about sequential Logon messages) was wrong.
Related
I'm building the Viber bot which will be served using different services. One of the problem is about getting the exact message which has been sent to the user.
The "received" event gives message_token, so I wonder if it's possible to use it in order to get the message.
Or I have to use my own mechanism of sync?
Viber message_token is an identifier for peer-2-peer connection between Viber server and/or your local or online server and not the actual message. Moreover, there is no "buffer" for messages to be stored both locally or online. There is an internal process to store message when recipient is offline and then resend message when it is got online but I couldn't find direct access to them.
I did something similar by storing incoming messages to SQL using datetime (milliseconds) as timestamp in order to identify the message. However, you can combine Token also for knowing the session or to be more specific user_ID, both are unique.
Hope that helps to work around your problem...
I want to create a chat where multiple independent conversations can be created between two users in my XMPP Server (MongooseIM).
I tried to do it with threads but it does not work since when I log in if the user has messages offline, the server marks the messages as read. Or if I send a message to the other user, the server marks all messages as read.
Do you think it would be the solution to use MUC?, or can I do it without using MUC?
I am developing Android Chat Application.
My requirement is to deliver messages to multiple devices.
Consider this scenario between two users User A and User B:
User A logs in and sends message to User B.
User B logs in from Device 1 and receives message from User A.
User B logs in from Device 2 but does not get message from User A.
According to my requirement User B should get message from User A in Device 2 as well.
How can I achieve this?
Thanks.
In XMPP, the message are only delivered in a single go either:
to the online resources sharing the highest priority,
to the first client that connect through offline message delivery.
However, if you want other clients to resync, you should rely on XEP-0313: Message Archive Management. This specifications describe how a client can access a message history and resync its state.
You can for example query the message archive for all messages after a given time. This will allow the client that connect to get all the messages it missed since it was last online:
<iq type='set' id='juliet1'>
<query xmlns='urn:xmpp:mam:0'>
<x xmlns='jabber:x:data'>
<field var='FORM_TYPE'>
<value>urn:xmpp:mam:0</value>
</field>
<field var='start'>
<value>2010-08-07T00:00:00Z</value>
</field>
</x>
</query>
</iq>
In addition to Mickael's answer, you should be aware of a few things. If you specify a full JID as your to address, then the message will only be delivered to that single endpoint.
Message deliver to multiple resources for the same user will only occur if
The to address is the bare JID
All connections have the same priority
The server is configured to deliver to multiple endpoints.
That last point is crucial. According to the specification, the server can handle messages sent to the bare JID in 2 ways.
Send to one of the connections with the highest priority. Which one is determined by the server, it could be the first one connected, the last one, or a random choice if there are multiple connections with the same priority.
Send to all of the connections with the highest priority.
So, unless you know your server supports and is configured to allow the second choice, you can't accomplish what you are trying to do anyway.
In order to participate in the instant messaging and presence activities, a client (i.e device) should establish a session on the server.
As given in XMPP Documentation
If there is already an active resource of the same name, the server
MUST either (1) terminate the active resource and allow the
newly-requested session, or (2) disallow the newly-requested session
and maintain the active resource. Which of these the server does is up
to the implementation, although it is RECOMMENDED to implement case #1. In case #1, the server SHOULD send a stream error to the active resource, terminate the XML stream and underlying TCP
connection for the active resource, and return a IQ stanza of type
"result" (indicating success) to the newly-requested session. In case #2, the server SHOULD send a stanza error to the newly-requested session but maintain the XML stream for that
connection so that the newly-requested session has an opportunity to
negotiate a non-conflicting resource identifier before sending another
request for session establishment.
(https://www.rfc-editor.org/rfc/rfc6120#section-7.7.2.2)
Therefore you should first decide the way you are going to handle the sessions, according to the app requirement.
Now since you are using Ejabberd you can configure it by defining the option resource_conflict
However, if you still want to use multiple sessions you can use Message Archive Management - XEP-0313
So you can store chat history on the server and then retrieve. This can be configured in ejabberd by using the option mod_mam
I'm using an Openfire server to support Jabber chat between Spark clients. I want to use GitHub's Hubot to monitor chatrooms and listen for users to send messages to Hubot, then log the messages. I'm having a hard time figuring out how I can get the timestamp of the message from the point of view of the Openfire server... is this even possible or should I just use the system time of the system running Hubot?
Use the system time of the receiving process. Only messages that were stored before you join a room will have timestamps with the server time.
If a quick fix session is created by server(acceptor) at say 9AM, but the StartTime is at 11AM. This means the session exists but not active.
If the server receives an unsolicited message from an exchange that it needs to send on this session, will it persist this if I have configuration PersistMessages=Y and sends it to the client(initiator) when it connects after 11AM?
No, it would not persist messages received before start time and would send you a reject message. The message will be rejected at the interface itself, message isn't handled. You would have to resend it to get a response.
QuickFIX does persist (but not send) messages before a session is connected. The sequence numbers are updated and when the session is connected and the first message is sent, the counterparty FIX engine will see the gap in the sequence numbers and request a resend. QuickFIX will then resend the persisted messages. However, depending on your QuickFIX configuration, the outgoing messages might be considered to be too old and rejected locally.
As I understand, these are kept to take into account timings under which corresponding exchange would accept the orders.
Application or its sub-modules do not need to maintain timings and take some action on closing the fix session. Rather, QuickFix shall automatically deactivate the session.
Persistence of the message or re-sesnding when the session becomes active does not look desirable to me.
You can rather maintain some kind of queue to buffer such messages in sending application, and send them only when the time matches with active session timings.
That's my thoughts, hope that helps.