When I have a FIX session between acceptor and initiator which side in general should be sending logout message first?
Also, is it fine to set session times on acceptor and initiator side to the same hours? Or maybe initiator should be configured for the shorter period to keep the communication safe and clear from errors?
Based on real project experience,
The connection was post trade feed, where our post trade gateways
used to connect with ECN (Electronic communication networks) like
Bloomberg, Tradeweb etc.
The ECN used to act as Acceptor and our gateways used to act as
initiator.
As initiator, its our gateways responsibility to initiate the
connection with ECN by sending LOGON message.
The gateways used to send LOGON and LOGOUT half an hour before/After
the markets open & closes respectively.
But in case there is some problem/error, even ECN used to send a LOGOUT message.
So, there is no hard and fast rule, who should send LOGOUT message.
Related
I’m building an instant messenger app on iOS that uses ejabberd. I’m currently testing the stream management feature and in particular the resumption that seems to work in most cases. However there is a case I don’t understand, that I can replicate through the following steps, taking in account the settings: resume_timeout: 30, resend_on_timeout: if_offline
at the beginning client A and client B are connected, no other resources are connected
client B crashes or disconnects in a not clean way
client A starts to send a bunch of messages (10+) very quickly
ejabberd sends an ack to A for each message sent to confirm that the messages reached the server
around 20 seconds since the crash, B reconnects. At this instant A receives an error for each message sent before
<message xmlns="jabber:client" from="clientB#mydomain" to="clientA#mydomain/resourceID" type="error" id="CFBF4583-209A-4453-2567-CCCC7894827E">
<body>test</body>
<active xmlns="http://jabber.org/protocol/chatstates" />
<request xmlns="urn:xmpp:receipts" />
<error code="503" type="cancel">
<service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />
</error>
</message>
I tried with ejabberd 16.01.
This happens 80% of the time; sometimes messages sent by A are correctly delivered to B on reconnection within the 30 seconds.
My questions are:
is this behavior correct? I would expect that no error is bounced to client A if an ack has already been received for a message.
since resend_on_timeout is set to if_offline and no other resource is connected, I would expect no errors at all. Am I correct?
Stream Management acks only indicate that the message has been received by your server. It doesn't imply that the message has been processed or delivered to the specified address. Even if it were delivered to the address, then that device can still return an error for the stanza.
This is really just a stab in the dark, but after having a glance over the ejabberd code, this could be what happens:
clientB#mydomain/ResourceB drops their connection, there is now a session awaiting resumption using ResourceB.
Client B reconnects, doesn't resume (because it crashed and lost its state).
Client B binds resource ResourceB again.
Now the server has to terminate the sleeping session that was waiting for resumption because client B requested the same resource.
The server checks whether there are other sessions because it is set to if_offline.
The server sees there is a session (the new session) and therefore chooses to bounce instead of resend.
So my theory is that if_offline only checks if there are other sessions when queue of unacknowledged messages needs to be handled, not at the time the message was originally received.
#xnyhps' response is correct, and I fixed this particular corner case for the next ejabberd release. However, #xnyhps is also correct that there are other corner cases, so if you want reliable message delivery, you should be using XEP-0313. The main feature of XEP-0198 is session resumption.
Working on a SIP application that requires monitoring call activity/state on a phone. My app (UA) is registered with a proxy server, as is the phone being monitored. I am making use of SUBSCRIBE/NOTIFY messages to tell the phone that I want to know about its "dialog" events, and once subscribed, this works fine. I am running into two problems:
I am requesting a subscription length of 900 seconds and consistently getting some absurd amount of 4000+ seconds returned from the phone.
There is the possibility that the phone may be unplugged while the subscription is active (don't ask, but, yes, this is a possibility). When this happens, I am not getting any type of notification as to the phone no longer being available. Consequently, I have to wait for my subscription to time out, try and renew it, handle the failure, and create a new subscription.
I realize that I can renew my subscription sooner than its expiration time, but is there a better way to go about it? For example, would I be able to get "presence" events and use them to know when the phone is there or not? Are those events always guaranteed to happen on phone start-up, and even so, since there is a proxy in the middle, would I even get the notifications, or would I still not know that the phone restarted and no longer recognizes my subscription(s)? Are these "presence" updates something that I can request from the proxy?
Any insight would be great; for the moment, I'm going to simply try and refresh my subscription on a much smaller interval, but I would love to know if there is a better way to go about it. Thanks in advance.
I don't know about a SIP agnostic way other than perhaps somehow pinging the phone but there is definitely a SIP way to do presence and that's using the same subscribe/notify model you are using for dialogs but in this case for presence. The relevant standard is RFC 3856 A Presence Event Package for the Session Initiation Protocol (SIP).
Typically the presence notifications would be generated by a SIP registrar, and since you say your phone is registering with your proxy it must also have a registrar built in. The registrar would notify your UA when the other phone's registration status changes such as when it first came online or when it failed to re-register. As far as the delay between a phone "disappearing" and the registrar server detecting it there's no prescribed way to do it. You can either wait for the registration period to expire and mark the phone as offline when it fails to register or alternatively the server could actively send a packet or even a SIP request such as an OPTIONS request to the phone and mark it as offline if it got a failure response, Asterisk uses te latter approach.
When a SIP UAC client registers with a SIP UAS Registrar, the SIP client provides a Expiry Header, which indicates that maximum amount of time after which a SIP client needs to re-register itself. If the SIP client does not re-register itself in this time period, then Sip UAS proxy/registrar server will mark the client as disconnected.
Proprietary SIP packages like FreePBX and Asterisk, proactively, send SIP OPTIONS to the client, continuously, at some interval, wherein the client responds with OK. This is a more proactive way of validating if SIP clients are online; however, this technique is proprietary and not part of the actual SIP specification.
I am implementing a VOIP application in which I work with SIP protocol. As per SIP I need to refresh my registration with SIP server at certain interval. But when my app goes in background, my keepalive handler is invoked only after 600 seconds as per documents os Apple. But this is not desired with SIP protocol. To be able to keep my connection alive with server and receive incoming call, I need to send registration message before 600 seconds even when app is in background. According to Apple documentation this is not possible but stilll I have seen apps on AppStore which runs in background and keeps their registration on with SIP server even when registration interval is 60 seconds. They keep app running in background throughout. So how is this possible? I know that playing silent audio in background will survive but then AppReview process will reject it. But if its so, how Apple allowed other such apps on AppStore? Is there some standard way to achieve what I have described above? Any help is appreciated.
You don't have to send the registration more often. You can do something like this: configure your server to send keep alive packages to your sip client in order to keep the TCP connection open. Your server should support TCP connection and your client should communicate over TCP since apple is very restrictive in background mode and only the TCP connection is allowed to remain open in the background (if your TCP socket is wrapped with CFReadStreamRef).
The problem is no the registration message, this can be configured by the client by specifying the time between the connection attempts, and the sip sever will be fine with an interval of one hour between 2 registration messages. The real problem is how will the server contact the sip client in case of an incoming call or IM. Most of the sip clients will not have a public IP adress but most probably they will be behind a NAT. So there is no way the sip server can open a direct connection to the sip client, for this reason you have to keep a socket open between your client and the server.
None of the app in the appstore is sending registration message more often than 600s.
Do you use your own library for sip or you use pjsip? If you use pjsip i can give you more hints. What SIP server do you plan to use?
Some hints:
make sure you set in your app-info.plist the required background modes to "App provides Voice over IP services" and "App plays audio"
in case your app will not be tied to your own sip server then provide a way for the user to disable the allow_contact_rewrite pjsip param (usually u want this to be enable for bypassing the nat problem) since some session border controllers are not happy about this feature
make sure, in case you capture the messages send form the sip thread in your main thread, you are using a method to post them in the main thread
here are described some other interesting issues
have a lot of coffee prepared :))
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.
I am basically writing a XMPP client to automatically reply to "specific" chat messages.
My setup is like this:
I have pidgin running on my machine configured to run with an account x#xyz.com.
I have my own jabber client configured to run with the same account x#xyz.com.
There could be other XMPP clients .
Here is my requirement:
I am trying to automate certain kind of messages that I receive on gtalk. So whenever I receive a specific message eg: "How are you" , my own XMPP client should reply automatically with say "fine". How are you". All messages sent (before and after my client replies) to x#xyz.com but should be received by all clients (my own client does not have a UI and can only respond to specific messages.).
Now I have already coded my client to reply automatically. This works fine. But the problem I am facing is that as soon as I reply (I use the smack library), all subsequent messages that are sent to x#xyz.com are received only by my XMPP client. This is obviously a problem as my own client is quite dump and does not have a UI, so I don't get to see the rest of the messages sent to me, thereby making me "lose" messages.
I have observed the same behavior with other XMPP clients as well. Now the question is, is this is a requirement of XMPP (I am sorry but I haven't read XMPP protocol too well). Is it possible to code an XMPP client to send a reply to a user and still be able to receive all subsequent messages in all clients currently listening for messages? Making my client a full fledged XMPP client is a solution, but I don't want to go that route.
I hope my question is clear.
You may have to set a negative presence priority for your bot..
First thing to know is that in XMPP protocol every client is supposed to have a full JID. This is a bare JID - in your case x#xyz.com with a resource in the end e.g. x#xyz.com/pidgin or x#xyz.com/home (where /pidgin and /home are the resource). This is a part of how routing messages to different clients is supposed to be achieved.
Then there are the presence stanzas. When going online a client usually sends a presence stanza to the server. This informs about e.g. if the client is available for chat or away for lunch. Along with this information can be sent a priority. When there are more than one clients connected the one with the highest priority will receive the messages sent to the bare JID (e.g. ClientA(prio=50) and ClientB(prio=60) -> ClientB receives the messages sent to x#xyz.com). But there are also negative priorities. A priority less than 0 states that this client should never be sent any messages. Such a stanza might look like this
<presence from="x#xyz.com/bot">
<priority>-1</priority>
</presence>
This may fit your case. Please keep in mind it also depends on the XMPP server where your account is located, which may or may have not fully implemented this part of the protocol.
So to summarize: I recommend you to look through the Smack API how to set a presence and set the priority to <0 for your bot client right after it connected.