I was using a very old queueinglib (maybe from ten years ago). In which Job is inhereted from cPacket, not cMessage.
Now I changed my IDE version from 5 to 6 and had to update queueinglib. When I do I am very suprised to see that Job is now inhereted from cMessage.
In my model, I have both internal and external messages(through datarate channel). For internal messages, it is okay to use cMessage but I need to use cPacket for external messages. Thats why my own message type was derived from cPacket.
Now I have messages derived from cPacket, but queueinglib blocks cannot cast them to Job. How can I solve this problem? Here are some ideas that I can think of:
-I can change queueinglib entirely but I don't want to do this to an external library. I believe it is using cMessage instead of cPacket for a reason.
-Multiple inheritence. I can derive my message type from both cMessage and cPacket but I saw in the manual that it is not possible.
-I can create a new message when transmitting between a block of mine and queueinglib. But then message ids will be useless. I will be constructing and destructing messages constantly..
So is there a better, recomended approach?
How can use queueinglib with cPacket instead of cMessage?
Viewed 24
1 Answers
The reason why Jobs are messages in the queueinglib example is because those packages never travel along datarate channel links so they don't need to be packets and the example is intentionally kept as simple as possible.
BUT: this is an example. It was never meant to be an external library to be consumed by other project, so it was not designed to be extensible. You can safely copy and modify it (I recommend to mark/document your changes in case you want to upgrade/compare the lib in future).
The easiest approach: modify Job.msg and change message Job to packet Job and you are done. And use Job as the base of your messages. As Job extends Message, the whole queuing library will work just fine.
Without modifying the queinglib sources: There are various fields in cMessage that can be (mis)used to carry a pointer. For example you could use setContextPointer() or setContolInfo() to set your packet's pointer (after some casting) whenever it enters the parts where you use the queuinglib, and remove the prointer when leaves. This requires a bit more work (but only in your code) and has it's advantage that the network packets do not contain anything from the queuinlib fields (which is a proper design) as data releated to queuing component are not meant to travel between network nodes (e.g. priority or generation).
Also using a proper external queuing library (like the one in inet's src/inet/queueing folder) would have been the best solution, but that ship has sailed long ago, I believe.
In short, go with the first recommendation.
Related