(OMNeT++) Where do packets go? - c++

I'm trying to do a project described also here: PacketQueue is 0
I've modified the UdpBasicApp.cc to suit my needs, and in the handleMessage() function I added a piece of code to retrieve the length of the ethernet queue of a router. However the value returned is always 0.
My .ned file regarding the queue of routers is this:
**.router*.eth[*].mac.queue.typename = "DropTailQueue"
**.router*.eth[*].mac.queue.packetCapacity = 51
The code added in the UdpBasicApp.cc file is this:
cModule *mod = getModuleByPath("router3.eth[*].mac.queue.");
queueing::PacketQueue *queue = check_and_cast<queueing::PacketQueue*>(mod);
int c = queue->getNumPackets();
So my question is this: is this the right way to create a queue in a router linked to other nodes with an ethernet link?
My doubt is that maybe packets don't pass through the specified interface, i.e. I've set the ini parameters for the wrong queue.

You are not creating that queue. It was already instantiated by the OMNeT++ kernel. You are just getting a reference to an already existing module with the getModuleByPath() call.
The router3.eth[*].mac.queue. module path is rather suspicious in that call. It is hard-coded in all of your application to get the queue length from router3 even if the app is installed in router1. i.e. you are trying to look at the queue length in a completely different node. Then, the eth[*] is wrong. As a router obviously contains more than one ethernet interface (otherwise it would not be a router), you must explicitly specify which interface you want to sepcify. You must not specify patterns in module path (i.e. eth[0] or something like that, with an exact index must be specified). And at this point, you have to answer the question which ethernet interface I'm interested in, and specify that index. Finally the . end the end is also invalid, so I believe, your code never executes, otherwise the check_and_cast part would have raised an error already.
If you wanted to reach the first enthern interface from an UDP app in the same node, you would use relative path, something like this: ^.eth[0].mac.queue
Finally, if you are unsure whether your model works correctly, why not start the model with Qtenv, and check whether the given module receives any packet? Like,, drill down in the model until the given queue is opened as a simple module (i.e. you see the empty inside of the queue module) and then tap the run/fast run until next event in this module. If the simulation does not stop, then that module indeed did not received any packets and your configuration is wrong.

Related

findModuleByPath("host") returns nullptr in OMNeT++

In OMNeT++ I'm working on example aloha. I try adding acknowledge message sent from server to the node. So, I have defined cModule *host and added host = findModuleByPath("host"); line to the initialize() method in Server.cc but it returns nullptr and I have seen the getModuleByPath() method also does the same work but throws and exception instead of returning a nullptr.
It cannot find the host module even though I have defined it. I believe I am missing something but I don't know what. Is there a good example of network (with multiple nodes) that also sends acknowledgement message?
There are several issues in using cModule *host = findModuleByPath("host") in initialize() of server.
According to 4.11.4 Finding Modules by Path that command leads to looking for a submodule named host inside the current module, i.e. in server. Of course, server does not contain host, so it results in returning nullptr. To find a sibling module called host one should use
cModule *host = findModuleByPath("^.host").
In Aloha there is no single host module, but a vector of modules. It means, that first host has the name host[0], the second - host[1] etc. Therefore, it would be possible to use:
cModule *host = findModuleByPath("^.host[2]")
Another way is the following command:
cModule *host = getParentModule()->getSubmodule("host", 2)
Be aware that initialize() is called sequentially in modules in the network and the order of choosing the next module is not guaranteed by the simulation environment, e.g. initialize() was called in host[1] but not yet in server.
Multi-Stage Initialization may be used to be sure that one stage of initialize() has been performed in all modules.

C++ Change Print Queue Owner

I want to know if it is possible to change the “Owner” name that is visible when you bring up the print queue to view the queued printer documents. I have a Windows Service that receives a document from a user and sends it a Windows printer, and the Owner is always the name of the user that logged into the workstation where the Service is running. I would like to change the “Owner” to something else, and this would be done in a C++ Windows DLL that the Windows Service loads and uses.
Added 8/30/16#9:14am ET
Thanks for the suggestion, Thomas. I should have mentioned my research, but it was long and empty. MSDN has a SetJob function which can take 1 of 4 structures (pJob = JOB_INFO_1…JOB_INFO_4). JOB_INFO_1, 2, and 4 have an LPSTR pUserName that appears to be what can be used to change the owner of the print job (Owner?). However, in the remarks section of SetJob it says:
“The following members of a JOB_INFO_1, JOB_INFO_2, or JOB_INFO_4 structure are ignored on a call to SetJob: JobId, pPrinterName, pMachineName, pUserName, pDrivername, Size, Submitted, Time, and TotalPages.”
And JOB_INFO_3 does not have this field in it. Nice.
I did not see any other functions that could maybe do this. Can you point me to something specific that I can research more? Or that is known to work? Thanks.
I'm not sure why MSDN says those fields are ignored. I change pUserName, pDocument, pStatus using SetJob with JOB_INFO_1 and it works perfectly.
Just be sure to set Position to JOB_POSITION_UNSPECIFIED.

Clojure: architecture advice needed

I'm writing a little clojure pub/sub interface. It's very barebones, only two methods that will actually be used: do-pub and sub-listen. sub-listen takes a string (a sub name) and do-pub takes two strings (a sub name and a value).
I'm still fairly new at clojure and am having some trouble coming up with a workable way to do this. My first thought (and indeed my first implementation) uses a single agent which holds a hash:
{ subname (promise1 promise2 etc) }
When a thread wants to sub it conj's a promise object to the list associated with the sub it wants, then immediately tries to de-reference that promise (therefore blocking).
When a pub happens it goes through every item in the list for the sub and delivers the value to that item (the promise). It then dissoc's that subname from the map and returns it to the agent.
In this way I got a simple pub sub implementation working. However, the problem comes when someone subs, doesn't receive a pub for a certain amount of time, then gets killed due to timeout. In this scenario there will be a worthless promise in the agent that doesn't need to be, and moreover this will be a source of a memory leak if that sub never gets pub'd.
Does anyone have any thoughts on how to solve this? Or if there is a better way to do what I'm trying to do overall (I'm trying to avoid using any external pre-cooked pubsub libraries, this is a pet project not a work one)?
You can do something like this:
Create an atom
publish function will update the atom value by the passed in value to the function
Subscribers can use add-watch on the atom to be notified of when the atom value changes i.e due to call to publish function
Use remove-watch to remove the subscription.
This way you will have a very basic pub-sub system.
I have marked Ankur's answer as the solution but I wanted to expand on it a bit. What I ended up doing is having a central atom that all client threads do an add-watch on. When a pub is done the atom's value is changed to a vector containing the name of the sub and the value being pub'd.
The function the clients pass to add-watch is a partial function which looks like
(partial (fn [prom sub key ref _old new] ...) sub prom)
where prom is a promise previously generated. The client then blocks while waiting on that promise. The partial function checks if the sub in new is the same as sub, if so it removes the watch and delivers on the promise with the value from new.

understanding RProperty IPC communication

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();
}

TDD for a medium complexity method

I've been out of touch with TDD for some time, and am very rusty. I'd appreciate some suggestions on how to TDD the method described below.
The method must find a web.config file in a user supplied application directory. It must then extract and return a connection string from that config file.
It returns null if for any reason the connection string isn't found, be it a bad path, no web.config, or no connection string in web.config.
My initial thoughts are to write a test with setup that creates a directory and writes a web.config file with a connection string. The test would then call my method with the created path and expect a non-null value back, and my initial test run would fail because my method stub always returns null.
Then, implement the method, and run the test expecting a pass. Then, as a pre-test (I forget the term), delete the created directory, and call the method expecting a null value.
First, I wouldn't have the method both find the file and extract the connection string. If your framework doesn't already have a method to determine if a file exists in a given directory, write a method to do then, once you have a file, write a method to extract the connection string from an open stream. For testing, then, you could supply a memory stream instead of having to actually create a directory and file.
Second, if you aren't depending on a failed compile being your first failing test, then write your first attempt at the method to throw a NotImplementedException. It's a small step, but when you write your first test, at least it will fail. Of course, the first test on an empty stream will expect it to return null and the first code you write will be return null, but that's ok. Your next test will force you to change it. Continue on from there until you've got your completed methods.
You appear to have several TestCases with several distinct setUp fixtures.
The FoundDirectory TestCase. The setUp creates the expected, valid file.
This can have several subclasses.
A connection string not found TestCase. The setUp creates the expected, but invalid file.
A bad path TestCase. The setUp creates the expected, but invalid file.
A no web.config TestCase. The setUp creates the expected, but invalid file.
A no connection string in web.config TestCase. The setUp creates the expected, but invalid file.
The DidntFindDirectory TestCase. The setUp assures that the directory doesn't exist.
The DidntFindFile TestCase. The setUp creates the directory but no file.
Make the object that hold you method (or the method itself) dependent on a IConfigLoader of some sort, that you would be able to mock :
public interface IConfigLoader
{
XmlReader LoadAppConfigFrom(string path);
}
Use it from your method to get the XML file you want to parse.
I suggest that the story in your question mixes several issues:
finding and opening a file,
loading data into a "configuration" (however represented)
attempting to get a specific parameter from a "configuration"
Point 3 is now a matter of how a Configuration behaves, and can be developed in TDD fashion.
Point 2 is now a matter of how a Configuration is constructed (e.g by a ConfigurationLoader), and can be developed in TDD fashion (e.g. against a StringReader).
Point 1 is now a matter of whether you can open a Reader for a specified file path. It is easy to add after completing point 2.