I am new to Veins and trying to implement a mechanism to detect if the WSM packet was received before. I am using the "psid" as the main variable to identify the packet - is it correct?
Will this type of code work? :
bool MyVeinsApp::msgReceivedBefore(int psid){
/*
This function will be used to determine if the message was received before
and should be discarded or processed further
*/
if(msg_log.find(psid) == msg_log.end()){
return false
}
else {
return true;
}
}
Here msg.log is a C++ data structure storing WSMs based on psid.
The psid only is an identifier for the service you are using (see WaveShortMessage.msg) and therefore not unique among messages of the same service. To distinguish between messages you need a unique message identifier.
A simple approach would be to use the id which every module in OMNeT++ gets:
msg->getId()
UPDATE: Please note that this id also is unique among all messages with the same content (see comment down below).
Related
I'm trying to see if there is a way to do more robust handling of partial decoding failures of Apollo generated Swift classes. Currently, if even one field of one object in an array fails to parse from the network response, the entire collection of objects fails to parse and our iOS client gets no data.
Our graphql is defined something like:
query mobile_getCollections() {
getCollections() {
// ... other fields
items {
activeRange {
expires // Int!
starts // Int!
}
}
}
}
So the Apollo generated Swift code is expecting non-nil Ints when decoding these values. However, due to a backend error (that we would like to make the mobile clients more resilient to), the API will occasionally send us a malformed date String instead of a unix timestamp Int. This causes parsing of the entire mobile_getCollections result to fail, because the Apollo generated query class typing can't be perfectly satisfied.
Ideally, I'd like to just throw out the one item in the collection that failed to be parsed correctly and leave the remaining items intact. Is it possible to do something like that using Apollo?
(Yes, I know the real answer here is to fix the backend, but is there anything I can do in the mean time to more gracefully handle similar partial parsing failure issues?)
So, I've advertised for DCCA application in my extension via fd_disp_register and I can parse and prepare the response message and at the end sending them from my callback function with no issue.
This always works if the answer message is prepared inside of callback function. But what if i want to reply the request message outside of my callback function ?
So, I tried it with a sample code. I changed the callback function logic so there were no sending message from it and instead another thread tries to fetch some information and send out the response.
This absolutely failed, because as soon as callback returns (with 0), the next action gonna take place (according to disp_action value) which is not in my favor.
So, I'd like to ask what is your solution to handle such case, I mean sending out the response messages outside of the callback function ?
Thanks.
I'm not sure I've ever done this before, but looking at libfdproto.h...
enum disp_action {
DISP_ACT_CONT, /* The next handler should be called, unless *msg == NULL. */
DISP_ACT_SEND, /* The updated message must be sent. No further callback is called. */
DISP_ACT_ERROR /* An error must be created and sent as a reply -- not valid for callbacks, only for fd_msg_dispatch. */
};
...it sounds like you want to set *act = DISP_ACT_CONT; and *msg = NULL; (because you've taken ownership of the message).
Does that work?
I am new to Protocol Buffers and currently I see the following problem:
We use proto2 syntax with Protocol Buffers 3.2.0 library and observe that required fields are not enforced during the serialization.
Here a basic example with Catch C++ tests:
syntax = "proto2";
package simple_test;
message SimpleMessage
{
required string field1 = 1;
required string field2 = 2;
}
#include "simple.pb.h"
#include <catch.hpp>
#include <string>
SCENARIO("Verify that serialization with missing required fields fails", "[protobuf]")
{
GIVEN("a message")
{
simple_test::SimpleMessage m;
WHEN("field1 is set and field2 is not and both are required")
{
m.set_field1("aaa");
THEN("serializing this message to string buffer must fail")
{
std::string buffer;
CHECK_FALSE(m.SerializeToString(&buffer));
REQUIRE(buffer.empty());
}
}
}
}
m.SerializeToString(&buffer) returns true and buffer.empty() is false.
What I know
required fields were removed in Protobuf v3.
My Questions
Is there a setting or any kind of config switch that I can enforce these checks with Protobuf v3?
What happens with the use case:
proto2 Message compiled with Protobuf v3 compiler. This message ends up with partially filled required fields and is going to be send to Protobuf v2 enpoint which enforces the required fields. Does this effectively mean that there were just bytes sent for nothing, because the message is invalid and will be rejected?
Should I downgrade from v3.2.0 to 2.x to disallow sending of incomplete messages at client side?
I came along this documentation which I've overseen before:
Standard Message Methods and there is the documentation for:
Standard Message Methods
Each message class also contains a number of other methods that let you check or manipulate the entire message, including:
bool IsInitialized() const;: checks if all the required fields have been set.
This is what I needed! Protobuf are great again!
Is there a setting or any kind of config switch that I can enforce these checks with Protobuf v3?
Have you tried building protobuf in debug config? I think you'll find that it'll assert in this case.
What happens with the use case:
proto2 Message compiled with Protobuf v3 compiler. This message ends up with partially filled required fields and is going to be send to Protobuf v2 enpoint which enforces the required fields. Does this effectively mean that there were just bytes sent for nothing, because the message is invalid and will be rejected?
In this case, the receiver can ParsePartialFromXXX to received what was sent. He can test message validity with message.has_xxx()
Should I downgrade from v3.2.0 to 2.x to disallow sending of incomplete messages at client side?
I wouldn't. Perhaps write a checker for each message type to assert that each required field is present. Better yet, think about it the proto3 way and treat a missing field as a default value in the receiver. The protobuf documentation advises never adding required fields to an existing message type and suggests 'thinking very carefully' before making fields required. You could take this to mean 'oops, the concept of required fields was an error'.
I would like to create something like this :
I have a module that does something like 'circuit switching' for a stream of messages. That is, it has a single inport and multiple outports. Once a message arrives at the inport, an outport is selected based on some logic (logic is not important in the context of the question). It is checked whether, there is any ongoing message transfer on the outport (for the first message, there won't be any). If there is no transfer, message is sent to that outport, otherwise, it is kept in queue for that particular outport. I need to decide data structure for this communication. Please advice
My idea is to have a map of outports and corresponding queues.
queue<message> m_incoming_queue;
typedef map<outport*,m_incoming_queue> transaction_map
if this is a good solution, i want to know how do I create a queue at the runtime? as in, I dont know in advance how many outports will there be, I create outports based on requirement.
Maybe something like:
// At beginning
typedef queue<message> MessageQueue
typedef map<outport*, MessageQueue> transaction_map
transaction_map tm() // Create the transaction map
// On receipt of each message
// (Some logic that determines outport* op and message m)
if(tm.count(*op) == 0)
{
// There are no queues yet, create one and insert it
tm.insert(transaction_map::value_type(*op, MessageQueue()))
}
// There is already a queue created, so add to it
tm[*op].push(m)
i'm studying this source base. Basically this is an Anim server client for Symbian 3rd edition for the purpose of grabbing input events without consuming them in a reliable way.
If you spot this line of the server, here it is basically setting the RProperty value (apparently to an increasing counter); it seems no actual processing of the input is done.
inside this client line, the client is supposed to be receiving the notification data, but it only calls Attach.
my understanding is that Attach is only required to be called once, but is not clear in the client what event is triggered every time the server sets the RProperty
How (and where) is the client supposed to access the RProperty value?
After Attaching the client will somewhere Subscribe to the property where it passes a TRequestStatus reference. The server will signal the request status property via the kernel when the asynchronous event has happened (in your case the property was changed). If your example source code is implemented in the right way, you will find an active object (AO; CActive derived class) hanging around and the iStatus of this AO will be passed to the RProperty API. In this case the RunL function of the AO will be called when the property has been changed.
It is essential in Symbian to understand the active object framework and quite few people do it actually. Unfortunately I did not find a really good description online (they are explained quite well in Symbian OS Internals book) but this page at least gives you a quick example.
Example
In the ConstructL of your CMyActive subclass of CActive:
CKeyEventsClient* iClient;
RProperty iProperty;
// ...
void CMyActive::ConstructL()
{
RProcess myProcess;
TSecureId propertyCategory = myProcess.SecureId();
// avoid interference with other properties by defining the category
// as a secure ID of your process (perhaps it's the only allowed value)
TUint propertyKey = 1; // whatever you want
iClient = CKeyEventsClient::NewL(propertyCategory, propertyKey, ...);
iClient->OpenNotificationPropertyL(&iProperty);
// ...
CActiveScheduler::Add(this);
iProperty.Subscribe(iStatus);
SetActive();
}
Your RunL will be called when the property has been changed:
void CMyActive::RunL()
{
if (iStatus.Int() != KErrCancel) User::LeaveIfError(iStatus.Int());
// forward the error to RunError
// "To ensure that the subscriber does not miss updates, it should
// re-issue a subscription request before retrieving the current value
// and acting on it." (from docs)
iProperty.Subscribe(iStatus);
TInt value; // this type is passed to RProperty::Define() in the client
TInt err = iProperty.Get(value);
if (err != KErrNotFound) User::LeaveIfError(err);
SetActive();
}