We use Autosar to implement automotive gateway, and the PDUR module can be configured to route message from one interface to other protocol interfaces.
My question is if we want to do message check, analysis or logging, how could we know what message routed by PDUR? should I configure all the message transfer to SW-C application layer for analysis or is there any other method to do above deep message inspection feature.
Thanks
Jack
When I hear analysis and logging, I already get bad headache, because of features, that are put into ECUs but rather should be tested with proper stress tests from outside, e.g. PDUs on network A is seen on network B after whatever milliseconds. For such logging, you usually need a EEPROM or FLASH with a certain P/E cycles, which will just add to the price of the ECU without much benefit. And it also impacts your ECUs performance.
Regarding PduR message based routing, you should be very careful because:
Depending on CanRxProcessing, the handling of the PduR routing is handled on Interrupt level, so your "deep message checks" increase your ISR runtime/locktime!
Certain features in Can and CanIf (and also other bus specific network components) might already discard received messages, so PduR might not even be informed about it (e.g. static DLC check, message in BasicCAN HRH is blocked by SW filtering)
Some messages might not be routed by PduR directly, like signal based routing is actually handled in Com not in PduR, maybe protocols are routed by protocol specific modules and not by PduR
CanTp can have multiple addressing formats, where the N_TA is in the first data byte. Here it is tricky to handle multiple connections, if you think about certina N_TAs not being routed
Not sure about SecOC, is the gateway only routing authenticated messages?
Some routed messages could be disabled/enabled on the fly (Routing path groups)
Routed messages from network to network usually have a so called routing relationships (Routing paths). In the end, there should be a table somehow, but this depends also on your implementation, e.g. Vector, ETAS, Elektrobit, ...
So, my opinion is, that deep message check, I don't see what you would gain at all here, in the ECU. I would rather prefer a proper Stress Test with certain tooling from the outside.
Related
One of the new features of MQTT 5 is the shared subscriptions feature, which allows client-side load balancing between multiple workers, so that multiple workers can be responsible for handling messages, but every message is only ever sent to a single server.
By default, this works with a round-robin approach, but I am in the need of a slightly more advanced scenario:
What I want is some kind of routing, so that one of the messages' properties gets used as some kind of routing key. I.e., I want multiple workers to be responsible for the messages, but all messages with value X in their routing key property should always go to the same worker, and all messages with Y should do as well. The workers for X and Y may be different, but all messages with X should always go to the same one.
Question 1: Is this even possible with MQTT 5? If so, what is the term I need to look for? I tried googling for this, but wasn't really successful (mainly, I guess, because I don't know exactly what to look for).
Now, supposed this is possible: How can I then handle cases where nodes join or leave? Then I still want only a single node to be responsible, so it would be great if the assignment was not statically, but could be adjusted dynamically (or even better, would adjust itself automatically). However, what I strictly need to avoid is that two messages with X ever go to different servers at the same time.
Question 2: Supposed, this is not possible – what alternatives do I have to MQTT 5?
You don't at a protocol level. That is the whole point of a shared subscription to distribute the incoming messages evenly across all the subscribers.
This also goes against the pub/sub paradigm, that messages are published to a topic not an individual subscriber.
If you want to route messages differently publish them to different topics. There is nothing to stop you republishing a message on a separate topic based on it's meta data once it's been received by a client if needed.
I'm looking at the Apple networking guidelines that suggest that the user should try to work with the highest level of abstraction possible when dealing with networking.
I'm working on a client-server app, where the server is master, and an iOS device is slave. These communicate over HTTP, establishing a connection that lives for the lifetime of the app's usage session. The app and the server synchronize assets over this connection.
My question is - what level of abstraction is appropriate for implementing bi-directional sync over HTTP? Is it sockets, NSURLConnection, some AFNetworking subclass, input/output streams?
There are a lot of possible good answers to this. I think all I can do is offer one pattern which has worked well for me but it may not apply to your needs and use cases. To restate my comment above "whatever you do will be a tradeoff between responsiveness, power consumption, data consistency, and implementation cost."
The level of abstraction I aim for is a set of service objects which expose an interface in terms of the application's domain models. The rest of the app, primarily objects in the controller layer, should be able to communicate with these services by passing models to methods (e.g. "fetchUserWithId:userId" or "createUser:user") and without any awareness of the urls, paths, or HTTP verbs involved at the network layer.
Those service objects can map domain model operations into paths, HTTP verbs, and possibly request bodies or headers. In most cases I find that the services themselves can then share a lower level service which accepts those values and constructs the actual HTTP request. This provides a single location to configure host names, set global headers, and manage a request queue via NSURLRequest, NSURLSession, AFNetworking, or whatever library you prefer.
I'll include completion blocks on my service object methods so that controllers can be notified of success or failure but try not to use those blocks to pass models back up to the controller layer. Instead I prefer to have controllers monitor Core Data or some other persistence layer and react to changes. That way controllers remain flexible and respond to any update in the models they are concerned with and do not assume that they are aware of all possible sources of changes to those models.
So far none of this addresses how you should check for remote changes to your models. The best option may be to design a system which does not need to do so. What if your client obtained a set of recent changes only when posting data to the server, could it still provide a good user experience? Could the server use push notifications to occasionally notify clients of updates?
If you must check for changes sockets or long polling are usually more responsive than short polling but it may be hard for roaming mobile clients to keep those connections open. All of these approaches also tend to keep the client's radios active and consume lots of power in the process.
Without knowing more about the problem I'd default to short polling but try to design interactions which allow this to be as infrequent as possible (e.g. one check when the app resumes). I also use HTTP features (etags, if-modified-since, or custom content ranges) to limit the size of responses when there are no changes. If you have a good service layer managing network requests that also gives you a good place to introduce rate limiting. Allowing controllers to express interest to fetching up to date information but deferring to the services to throttle or batch requests based on what the rest of the app is doing (e.g. don't repeat the same request if those models were updated recently unless the user deliberately triggered the action).
We're looking to implement ActiveMQ to handle messaging between two of our servers, over a geographically diverse environment (Australia to the UK and back, via the internet).
I've been looking for some vague indicators of performance round the net but so far have had no luck.
My question: compared to a DIY TCP/SSL implementation of basic messaging, how would ActiveMQ perform? Similar systems of our own can send and receive messages across Australia in 100-150ms, over a SSL layer with an already established connection.
Also, does ActiveMQ persist its TLS/SSL connections, thus saving a substantial amount of time that would already be used in connection creation/teardown?
What I am hoping is that it will at least perform better than HTTPS, at a per-request level.
I am aware that performance can vary remarkably, depending on hardware, networks, code and so on. I'm just after something to start with.
I know the above is a little fuzzy - if you need any clarification please let me know and I will only be too happy to oblige.
Thank you.
What Tim means is that this is not an apples to apples comparison. If you are solely concerned with the performance of a single point to point connection to transfer data, a direct link will give you a good result (although DIY is still a dubious design decision). If you are building a system that requires the transfer of data and you have more complex functional requirements, then a broker-based messaging platform like ActiveMQ will come into play.
You should consider broker-based messaging if you want:
a post-office style system where a producer sends a message, and knows that it will be consumed at some point, even if there is no consumer there at that time
to not care where the consumer of a message is, or how many of them there are
a guarantee that a message will be consumed, even if the consumer that first handle it dies mid-way through the process (transactions, redelivery)
many consumers, with a guarantee that a message will only be consumed once - queues
many consumers that will each react to a single message - topics
These patterns are pretty standard, and apply to all off the shelf messaging products. As a general rule, DIY in this domain is a bad idea, as messaging is complex (see http://www.ohloh.net/p/activemq/estimated_cost for an estimate of how long it would take you do do same); and has many existing implementations of various flavours (some without a broker) that are all well used, commercially supported and don't require you to maintain them. I would think very hard before going down to the TCP level for any sort of data transfer as there is so much prior art.
I'm in the planning phase of our new site - it's an extension of some mobile apps we've built. We want to provide our users with a central point for communication and also provide features for users who don't want to/can't use the mobile apps. One of the features we're looking at adding is a reputation system similar in nature to the SO badge system. We're designing the system to use SOA.
I don't want to have to code all of this logic into the main app as discreet chunks. I'm thinking of creating a means to accomplish this which will allow us to define new thresholds and rules for gaining reputation and have them injected into some service. The two ways I've thought of doing this so far are:
To look for certain traits in a users actions and respond, this would mean having a service running that can run through the 'plugged in' award definitions and check for thresholds that have been met and respond appropriately.
To fire events when the user performs actions - listen out for those events and respond appropriately. Because the services which will be carrying out these actions are running in separate app domains potentially on separate servers the only way I can see having a central message bus to listen and respond to these events is by using something like MassTransit, nServiceBus or Rhino.Esb.
I know that using a service bus can very easily be inappropriately designed into an application that simply doesn't need it and most times - unless you're integrating disparate, heterogenous systems - you most likely won't need one when designing a new system but I'm a bit lost for options as to the best way to do this. I don't like the idea of having a service hammer the Db all the time in the background. But it does sound like it might be a lot simpler early on - later on - I dread to think!
Has anyone here designed a system like this? How did you accomplish this? We're designing for high throughput as we expect there will be times when the system will need to be able to cope with bursts of users.
I've designed a system that had similar requirements. To achieve this the key elements were:
Plugins
Event messaging - using Emesary
The basic concept is that the core is not aware of exactly which module will perform any given task.
The messages are defined and at points within the system they are dispatched. The sender is not aware if the message is required. This effectively decouples vast chunks of the system.
So to perform a job some code is plugged in, that registers with the event messaging bus and will receive messages. When it receives a message that it needs to process it will process it.
The Emesary code is extremely small and efficient in the first instance I've called it (Emesary and you're free to use it; or from Emesary CodePlex
As the system becomes more complex it is possible that there are lots of events flying about, if you get more than 20k a second it was always in my design to add filtering and routing (implemented by the recipient interface being extended to allow a recipient to specify messages it wants to receive during registration). I've never needed to add this filtering because Emesary is sufficiently efficient that it is the processing of the messages that takes the time.
I've build a version of Emesary which bridges two Notifiers across disparate systems using WCF, Corba and TCP/IP. I investigated using RabbitMQ and decided it was possible to use this underneath Emesary if needed.
Base Class Diagram
Scalable server.
This is a fairly complex example however it shows where Emesary fits in. In this diagram anything with a drop shadow can have multiple instances and this is managed outside of what I'm trying to explain here.
I am implementing some networking stuff in our project. It has been decided that the communication is very important and we want to do it synchronously. So the client sends something the server acknowledges.
Are there some general best practices for the interaction between the client and the server. For instance if there isn't an answer from the server should the client automatically retry? Should there be a timeout period before it retries? What happens if the acknowledgement fails? At what point do we break the connection and reconnect? Is there some material? I have done searches but nothing is really coming up.
I am looking for best practices in general. I am implementing this in c# (probably with sockets) so if there is anything .Net specific then please let me know too.
First rule of networking - you are sending messages, you are not calling functions.
If you approach networking that way, and don't pretend that you can call functions remotely or have "remote objects", you'll be fine. You never have an actual "thing" on the other side of the network connection - what you have is basically a picture of that thing.
Everything you get from the network is old data. You are never up to date. Because of this, you need to make sure that your messages carry the correct semantics - for instance, you may increment or decrement something by a value, you should not set its value to the current value plus or minus another (as the current value may change by the time your message gets there).
If both the client and the server are written in .NET/C# I would recommend WCF insted of raw sockets as it saves you a from a lot of plumbing code with serialization and deserialization, synchronization of messages etc.
That maybe doesn't really answer your question about best practices though ;-)
The first thing to do is to characterize your specific network in terms of speed, probability of lost messages, nominal and peak traffic, bottlenecks, client and server MTBF, ...
Then and only then you decide what you need for your protocol. In many cases you don't need sophisticated error-handling mechanisms and can reliably implement a service with plain UDP.
In few cases, you will need to build something much more robust in order to maintain a consistent global state among several machines connected through a network that you cannot trust.
The most important thing I found is that messages always should be stateless (read up on REST if this means nothing to you)
For example if your application monitors the number of shipments over a network do not send incremental updates (+x) but always the new total.
In a common think about network programming, I think you should learn about :
1. Socket (of course).
2. Fork and Threading.
3. Locking process (use mutex or semaphore or others).
Hope this help..