Re: Patching MTX for our use
Posted: Thu Apr 22, 2010 4:31 pm
not sure if this also sounds too simpistic, this is how I handle streaming vs polling (simultaneously) in my own code:
1) every msgs going out gets 'tagged' and waits for the response coming back with a matching 'tag' - if timeout the originator gets notified and then it gets pulled off the waiting list and goes on a backburner list - so I can pull it later for debug or dump it to log .. usually this means that I don't have support for the command in my firmware
2) anything that doesn't have a matching tag (most likely a streamed msg) gets delegated out to whoever wants to get a shot at parsing it .. this also allows me to dump to log too. think observer + chain of responsibility.
the above also lets me run different streams at different rates without increasing bandwidth needs. I can stream things like clt temp every 1s without having it get streamed in another higher freq stream.
the above also has other infrastructure required .. most of which I left out. I'll look over mtx code too.
1) every msgs going out gets 'tagged' and waits for the response coming back with a matching 'tag' - if timeout the originator gets notified and then it gets pulled off the waiting list and goes on a backburner list - so I can pull it later for debug or dump it to log .. usually this means that I don't have support for the command in my firmware
2) anything that doesn't have a matching tag (most likely a streamed msg) gets delegated out to whoever wants to get a shot at parsing it .. this also allows me to dump to log too. think observer + chain of responsibility.
the above also lets me run different streams at different rates without increasing bandwidth needs. I can stream things like clt temp every 1s without having it get streamed in another higher freq stream.
the above also has other infrastructure required .. most of which I left out. I'll look over mtx code too.