My question mainly will be related to ISO8583 for MTI "0800" regarding "logon request".
The question is, what if the client did not initialize with "0800" previously? So he just sends a message with MTI other than "0800".
For instance, if the client sent "0200", but not yet send "0800" previously, how we should tell him that he must do "0800" first:
Should it be using the same ISO8583 message class from the request?. For instance, when user send a message with MTI "0200", but because he did not logon previously with "0800", we give response "0220"
Or should it use "08xx" MTI response for every request sent by the user when they did not initialize a "logon request"?. For instance, even user sent MTI "0200", we will still give them "0820" instead "0210" because he did not login yet.
I am sorry if maybe my question does not make sense, I just a few days working with ISO8583. I hope someone can help me answer my question with a general practice or even best practice of ISO8583, or just please correcting me :).
Thanks in advance.
Regards.
When you send a 0800, you should expect a 0810 in response.
If, on the other hand, you receive a 0800, you should reply with a 0810.
Related
I've got following error while trying to send a message to a specific telegram channel:
TimedOut: Timed out
The read operation timed out
the method which I used from python-telegram-bot was send_message.
Although my bot got this error but it still sent the message to the channel and because I did not catch that exception all data from the message was lost but I really need to remove my messages from that channel after a specific period of time.
Is this OK that the bot sent the message even though it got Timed Out? How can I prevent this from happen again or remove this kind of messages from the channel after being sent?
Time out errors mean that TG didn't send a response to your send_message request quick enough. It does not necessarily mean that the request wasn't processed - that's why the message may still be sent. However, without response from TG, you don't have the message id of the resulting message and it will be hard to impossible to delete it.
You can try to increase the time that PTB waits for a response from TG. THis can be done in different ways:
with the timeout parameter of send_message
with Defaults.timeout, if you're using PTBs Defaults setup
by specifying it via the request_kwargs that you pass to Updater
You may want to have a look at this wiki page on networking.
Disclaimer: I'm currently the maintainer of python-telegram-bot
After a couple of hours reading here and there, and passing timeout=30 to context.bot.send_audio and getting an error that says unknown parameter even though send_audio's docs clearly states it takes a timeout param, I found that you can fix this by passing the timeouts to the Application upon building it:
application = ApplicationBuilder()
.token(bot_data["token"])
.read_timeout(30)
.write_timeout(30)
.build()
This fixed my bot. Hope this helps you as well.
So I managed to connect to the websocket with my API token and I do get notifications. For incoming calls, I do get a push with all info like so:
{"type":"push","targets":["stream"],"push":{"type":"mirror","source_device_iden":"XXXXXXX","source_user_iden":"ujC7S24sQxw","client_version":206,"dismissible":true,"title":"5555551212","body":"Incoming call","application_name":"Pushbullet","package_name":"com.pushbullet.android","notification_id":"6","icon"
"Big value here"}}
So I can see that call came from 555-1212 (I changed number for privacy) and it all makes sense. However, for SMSs, all I get is a notification that SMS changed. No body field so I can't see where it came from and what the message is. All it says is sms_changed for type:
{"type":"push","targets":["stream"],"push":{"type":"sms_changed","source_device_iden":"XXXXXXXXX"}}
What am I doing wrong? I would like to get the SMS message and sender info so that I can publish it. Any and all help will be greatly appreciated.
This is not publicly documented yet and we might be changing the implementation in the near future so I'm hesitant to make it public. Also I don't know the specifics of the current implementation.
You can view how it works right now by using www.pushbullet.com and looking at the network traffic (in chrome inspector) when you do SMS stuff on the website.
According to XEP-0220 the Authoritative-Server receives via a new connection db:verify and sends a go or no-go back to the Receiving-Server.
How can he send the db:verify to an other server without having a established connection?
According to the RFC a proper XMPP stream is initialized by stream:stream and stream:features. But then we are stuck in a loop cause he wants to authenticate again.
I am pretty sure I missed something here. I appreciate any help.
Cheers
Answer and quote from jabber mailing list:
You have to distinguish between authenticated and unauthenticated
streams. You can, and in fact have to, exchange dialback elements over
unauthenticated streams. So there is no loop.
I missed the point that only <message/>, <presence/> and <iq/> require authentication.
Our system receives ISO8583 messages which we decode and handle appropriately. Now we are getting invalid ISO messages in between which our system can't handle. In fact, it sends nothing in return. This causes a timeout on the other side. As a consequence, the (invalid) transaction is reverted which then causes quite a messup as there is nothing to be reverted.
Can anyone give me a clue on how to deal with/answer an invalid/undecodable ISO8583 message? Is there a standard answer (e.g. 'NAK' like)?
According to the ISO-8583 spec, 6XX (or 16XX, if you're using the '93 version)-class messages are appropriate for administrative notifications. Generally, a 644 or 1644 MTI is prescribed for notifying the sender of a problem processing a message, where
X6XX - Indicates an administrative message, often containing the details of a failure
XX4X - Indicates that the message is a notification; the sender is not to repeat the message
XXX4 - Indicates the source of the message (acquirer/issuer/other); here, it's Other
Putting it all together, your message should have at least the following fields
MTI: 1644
DE-24 (Function code): 650 (Unable to parse message)
Of course, you're to include the standard message identification fields: DE-7,11,12,39. These fields will be necessary for the message sender to match your response with the request.
I don't think there is a standard way of handling invalid ISO 8583 request messages. You didn't say why you are receiving invalid request messages, and without knowing that it is difficult to suggest how you should handle them.
Depending on the situation it may be best not to answer invalid ISO 8583 requests. In fact I know of systems that not only don't answer invalid request messages but will also blacklist the device that sent the invalid message and refuse to answer all other messages from it.
If you do decide not to respond to invalid request messages then as you have found out the client is likely to time out and then attempt to reverse the transaction. This is not usually a problem because servers will usually respond with an approval message to reversal request for transactions that don't exist. Remember that when a client times out after sending a request, it doesn't know if the request was processed or even if the request was received. So a server has to be prepared to handle both 1. a request that was received and processed (by undoing the transaction and then responding with an approval), and 2. a request that was never received/processed (by sending an approval). NOTE: In case 2 there is no need to undo the transaction because the transaction never took place.
From my experience with integrating ISO links, invalid ISO messages are usually, by industry standard, handled by a dropping down of the acquring host's connection followed by an angry mail from the acquirer's service provider accusing you of segfaulting down their mainframe.
Other than that different implementations, when implemented well, will handle invalid messages differently, from what #kolossus said in case the parser fails completely, to a normal **10 response with a specific response code such as RC 12 "Invalid transaction" when just some subfields don't make sense (such as problems with packaging of the complex subfields with tokens, track2 parsing etc)
The practical reason why #kolossus solution doesn't really make sense and why Stuard has a point is, if the client has issues of forming the ISO messages, then it almost certainly has a problem with parsing them too, so another ISO message doesn't really tell the client anything except provoking a parser exception on his side too.
End result will be the same - a technical reversal by the client, just not after a timeout. Basically, with iso8583, the best way to handle invalid messages is to not have them, there's no clean way.
hi
I cannot see any explanation of the implementation of the collapse_key.
I think i understand what it does but not how it do it!
Android Cloud to Device Messaging Framework
I have a C2DM framework set up and sending 4 types of messages to many phones.
String messages very basic looks kind of like this:
type:name:uuid
type:name:uuid:number
type:uuid:id
If the phone is off many of this can get piled up waiting for phone on-line.
as far as i can tell my system works but what will the collapse_key do for me here?
addEncodedParameter(sb, "collapse_key", "no_ide_what_to_put_here");
You mentioned retrying the same message 3 times and using the same key value. It doesn't really have to be the same message. If you've got a message that indicates the current price of a stock, for instance, and you really only care about the latest price, then you could send different messages with the same key. When the device comes back online, it only gets the latest price quote message.
This may have been what you were saying already, but wanted to make it clear it's not only for "retrying sending same message".
I found this text: “collapse key” used for overriding old messages with the same key on the Google C2DM servers" I think if im retrying sending same message 3 times I must use same key value right. Google cloud server will send the latest msg with the same key value
...but be aware of the following (from http://code.google.com/intl/sv-SE/android/c2dm/):
"Note that since there is no guarantee of the order in which messages get sent, the "last" message may not actually be the last message sent by the application server."
But maybe this is not an issue if you don't generate a lot of messages.