I use the The Push Notification Binary Interface cmd=2
This is format :
Q1: Can I send some device_id in one frame? For example:
item id = 1 , device_tocken #1
item id = 1 , device_tocken #2
item id = 1 , device_tocken #3
item id = 2 , message
item id = 3 ...
and etc
Q2: How I can receive the response error ?
The documentation said: If you send a notification that is accepted by APNs, nothing is returned.
If I make SSL_read after SSL_write and package was accepted by APNs, the program is waiting in SSL_read command.
r = SSL_write(ssl, out_buffer, size);
int len = SSL_read(ssl, in_buff, 6);
If I read from ssl channel into single thread - I have segmentation fault.
Q3: Do You know the link to example of use this protocol?
It's not clear from the documentation, but I don't think you can send multiple device tokens in the same frame, simply because if you get an error response of an invalid device token, you won't be able to know which device token it refers to. If, on the other hand, your frame contains a single device token and a single message identifier, then an error response containing that message identifier will tell you exactly which message caused the error.
You should use a non-blocking read for attempting to read the error response. I don't know how you write that in C, but there must be a way to specify some timeout or to call a read method that specifies a timeout. If there is nothing to read, the method will return after the timeout is elapsed.
The APNS docs contain samples for sending notifications in the older formats (0 and 1). I suggest you use format 1 (which supports error responses), since I don't see any advantage of using the newer format 2.
Related
EDIT: The main problem has been solved, but I stilla have a question, check the third attempt to see it.
I'm trying to send a Diagnostic Request that is not defined on my Diagnostic Description.
I have the following on my script:
variables
{
//Diagnostic Request that doesn't exist on the .cdd
diagRequest ReadParameter Parameter_Req;
}
on preStart
{
//Sets Diganostic Target just as it was configured
diagSetTarget("DUT");
}
on key 's'
{
//Setting request size to 3 bytes
//I asigned the size to a variable to be able to read which value it had after resizing if but
//everytime I got 0xFF9E or something like that the case is it seems the diagResize is not working
diagResize(Parameter_Req,0x3);
//Setting bytes on the request to creat 22 05 70 (read by identifier)
Parameter_Req.SetPrimitiveByte(0,0x22);
Parameter_Req.SetPrimitiveByte(1,0x05);
Parameter_Req.SetPrimitiveByte(2,0x70);
//Send Request
diagSendRequest(Parameter_Req);
}
But the request is never sent, nothing new is seen on the Trace window. Does anybody know what I am doing wrong? I tried this with a Diagnostic Request that is declared on the Diagnostic Description and it works the request is sent, so I know my diagnostic configuration is OK. Also, no error is reported by CANoe
Thanks for your help
Edit: I also tried this other way
variables
{
byte ReadDID0570[3];
}
on preStart
{
//Sets Diganostic Target just as it was configured
diagSetTarget("DUT");
}
on key 's'
{
//Set bytes and Send Read Request
ReadDID0570[0] = 0x22;
ReadDID0570[1] = 0x05;
ReadDID0570[2] = 0x70;
//Send request
DiagSendRequestPDU(ReadDID0570, elCount(ReadDID0570));
}
But the result the same absolutely nothing happens.
Edit After the suggestion of M. Spiller
variables
{
diagRequest * Parameter_Req;
}
on preStart
{
//Sets Diganostic Target just as it was configured
diagSetTarget("DUT");
}
on key 's'
{
//Resize the request to three bytes
diagResize(Parameter_Req,0x3);
//Set bytes
Parameter_Req.SetPrimitiveByte(0,0x22);
Parameter_Req.SetPrimitiveByte(1,0x05);
Parameter_Req.SetPrimitiveByte(2,0x70);
//Send Request
diagSendRequest(Parameter_Req);
}
This worked! The request is sent, although is not showed in the Trace window, I know it was sent because the response could be seen on Trace. Now my only question is how can I use diagGetLastResponse(Parameter_res); and on diagResponse Parameter_res using this same method to declare the response?
diagResponse * Parameter_Res;
Because those functions receive the name of the request/response declared on the Diagnostic Description, but using this method the type of request is * so how do I use it?
You have used diagGetLastResponse(Parameter_res) to save the response to the Parameter_res variable. Since this is a variable declared with *, you won't have access to the parameters as specified in your Diagnostic Description.
You can make use of the function diagInterpretRespAs to convert this response variable to a suitable class according to your description file. After this, you can use diagGetParameter to get the parameter with the resolution and offset considered.
Otherwise, you can simply use the raw response variable and use diagGetPrimitiveByte to access the bytes in the response.
I am using Unetstack software along with Unetpy. I wish to retrieve transmit and recieve notifications when I run .py file which imports Unetpy python library. I followed this tutorial
I am successfully able to connect to the localhost and print values like phy.MTU and so on. When I transmit a packet I also receive a reply saying AGREE on the command prompt.output_of_my_script
my_script
Can you please help me in receiving Txframentf and rxframentf along with data payload.
I have made changes posted in bug reports suggested in this linkeven.
Please guide me on how to print notifications for rxframe and txframe.
Thank you``
Your script is fine until the last line:
print(phy << org_arl_unet_phy.TxFrameNtf())
Here you are trying to send a TxFrameNtf to the physical agent. This does not make sense, as it is the physical agent who sends you such a notification when a transmission is completed.
By the time you reach this line, you should have already received the notification as txntf as long as the transmission was completed within 5 seconds (timeout=5000). To print out the notification, all you need to do is:
print(txntf)
I just tested this against the 3-node-network.groovy sample. I am using unetpy-1.3b5 and fjagepy-1.4.2b3. Here's the modified code:
from unetpy import *
modem = UnetGateway('localhost', 1102)
phy = modem.agentForService(Services.PHYSICAL)
print(phy.MTU)
print(phy.basebandRate)
print(phy << org_arl_unet_phy.TxFrameReq(to=3, data=[1,2,3,4]))
txntf = modem.receive(timeout=5000)
print(txntf)
and the output:
16
4096
AGREE
TxFrameNtf:INFORM[type:1]
You can see that the TxFrameNtf is correctly received.
For reception, you need to subscribe to the agent's notifications and then receive a frame:
modem.subscribe(phy)
rxntf = modem.receive(org_arl_unet_phy.RxFrameNtf, timeout=5000)
print(rxntf)
Assuming you receive a frame within the 5 second timeout specified (in this example, on node 3), this should print out something like:
RxFrameNtf:INFORM[type:CONTROL from:1 to:3 protocol:0 rxTime:34587658 (4 bytes)]
You sent a datagram through some agent that supports the DATAGRAM service. There may be many agents that support this service (not just the physical layer). In any case, that datagram would be received on a different node, and so you wouldn't expect to receive DatagramNtf on the transmitting node.
The RangeReq should yield a RangeNtf if successful, but that might take more than the default receive timeout of 1 second, depending on how far node 2 is. So you might want to try a longer receive timeout to see if you get your notification.
To access the data from payload from the rxntf, you can try print(rxntf.data).
When I run a fetch command UID FETCH 170930:170930 BODY[] I get the response 88924 FETCH (UID 170920 FLAGS (\Seen)). I wasn't expecting to retrieve a message with a UID out of the range specified. Is this normal IMAP behaviour? The 170930 UID came from watching the folder with an IdleManager only moments earlier, so I have no reason to believe that a message with that UID doesn't exist on the server.
The fetch request I've posted here is a guess based on the Java code I'm using to execute it. At the very least it should still be requesting only messages within that range:
Argument args = new Argument();
args.writeString(Long.toString(start) + ":" + Long.toString(end));
args.writeString("BODY[]");
Response[] r = protocol.command("UID FETCH", args);
Response response = r[r.length - 1];
An IMAP server is required to send you FETCH responses in certain cases. Sometimes the server is required to wait with responses, but it's never required not to send you any.
If you send a command that requires two response, and someone else does something that requires one response to you, then you get three responses. That something might be to change the flag on a message (requires FETCH ... FLAGS ... to you, although there's no promptness requirement) or send you some mail (requires EXISTS to you).
I'm intending to use multi-part messages in ZeroMQ, but I need to know what happens to the initially enqueued message parts when I get a send error before the last message part is sent.
For example, lets say I have a PUSH socket and I am sending a two part message because I am collecting the header and body from different sources. What happens if the header sends fine, but there is an error sending the body? Does the header remain in the socket's outbound queue until I attempt to send another message, or does the header get dropped due to the error in the body send?
Perhaps some code will make the question more precise:
int header[] = {1, 2, 3}; // <- Header From Source 1
int body[] = {4, 5, 6, 7, 8, 9}; // <- Body From Source 2
void *ctx = zmq_ctx_new();
void *push = zmq_socket(ctx, ZMQ_PUSH);
zmq_connect(push, "tcp://localhost:7890");
int headerSent = 0;
int bodySent = 0;
headerSent = zmq_send(push, &header[0], sizeof(header), ZMQ_SNDMORE);
if (-1 != headerSent)
{
bodySent = zmq_send(push, &body[0], sizeof(body), 0);
// What if ^-- this fails?
}
// Do some other processing to prepare a new header and body here...
headerSent = zmq_send(push, &header[0], sizeof(header), ZMQ_SNDMORE);
if (-1 != headerSent)
{
bodySent = zmq_send(push, &body[0], sizeof(body), 0);
}
Is it possible for me to have a message with two headers here, or does ZeroMQ discard the initial message parts that were submitted with the ZMQ_SNDMORE flag when a subsequent send fails due to (e.g.) interruption from a signal? I'm hoping that is the case because the documentation on zmq_send promises that all message parts will be delivered, or none of them will be delivered. However, I'm not sure how the library decides which message parts are from the same message. Does it consider two message parts to be from the same message if a send error occurs in between them?
ZeroMQ Guide:
When you send a multipart message, the first part (and all following parts) are only actually sent on the wire when you send
the final part.
You will receive all parts of a message, or none at all.
What you could always do is send single part messages and assemble them and manage failure on the receiving end
Recent update: Pieter Hintjens: The End of ZeroMQ Multipart
I don't know exactly what will happen, however logic dictates one of 3 outcomes:
The 2nd frame, which failed, will have successfully processed the 0 in the multipart parameter instead of ZMQ_SNDMORE. The first message will be dropped, and the 2nd message will start anew.
The 2nd frame, which failed, will not have successfully processed the 0 in the multipart parameter instead of ZMQ_SNDMORE. The first message will still be open, your 2nd "header" will be frame 2, your 2nd "body" will be frame 3, and the message will just send with 3 frames instead of 2, erroneously
ZMQ will have its pants around its ankles, and be in some error state which will respond in unexpected ways.
My expectation is that the 2nd possibility is what will happen, if the call fails that it should produce zero side effects so it will be as if it never happened. This is supported by the info on the man page talking about the several error types that you might encounter. In particular it looks like it should be a very rare/exceptional situation where the first part of a multipart message would be accepted by the 2nd would not.
I'm using Twilio to send sms's with appengine. Twilio doesn't accept sms's longer than 160 characters so I have to split them. I am splitting the sms's and sending them as follows:
def send_sms_via_twilio(mobile_number, message_text):
client = TwilioRestClient(twilio_account_sid , twilio_auth_token)
message = client.sms.messages.create(to=mobile_number, from_=my_twilio_number, body=message_text)
split_list = split_sms(long_message)
for each_message in split_list:
send_sms_via_twilio(each_message)
However I found that the order of sending varied. For example sometimes I'd recieve message 2/5 then 1/5 then 4/5 etc and other times the order would be correct. The order of the split_list is definately correct. To overcome the incorrect order of the sms's I tried
for each_message in split_list:
deferred.defer(send_sms_via_twilio, each_message, _countdown=1)
However I encountered the same problem. I then tried
for each_message in split_list:
deferred.defer(send_sms_via_twilio, each_message, _countdown=1, _queue="send-text-message")
and defined my queue as
- name: send-text-message
rate: 1/s
bucket_size: 10
max_concurrent_requests: 1
retry_parameters:
task_retry_limit: 5
Thinking that the issue was concurrency (running in python27) and that if I limited max_concurrent_requests this issue would be solved. However the issue is still present i.e. the texts still get sent in the wrong order. I checked the logs but couldnt see any notification of task failure - they just seem to be executing in the wrong order.
Is there something I am missing? How can I fix this issue.
Note that the SMS messaging (specifically the underlying protocols like SMPP) are asynchronous by definition. It means there is no way you can specify the order of distinct SMS messages.
There is a way to specify the order of SMS packets by using the UDH (user defined headers) in the binary body of those messages. But this works only for long SMS messages -- those that are too long to be sent in one message. For example, if your msg exceeds 160 GSM-7 characters or 80 UTF-16 characters it will be send as more than one message with UDH.
In that case the mobile phone won't show message parts as they arrive. It will collect them in memory until the last one comes and then assembles them in the right order. For the end user this is just a message longer than usual and you don't have to write "1/3", "2/3", ... in the message.
Disclaimer: I work for a company that enables you to send and receive both multiple binary messages with user-specified headers (UDH) and/or standard long messages.
If you are not tied to Twilio try using SMSified. They automatically split the message for you, insure it is in the correct order, and add "1/2, 2/2..." to the end of the message. In other words you just send the complete message to their REST API, no matter the length, and they handle the rest. Since they also use a REST API you can continue to use Python.