A lot of people who have never used RTI’s infrastructure ask, “How do I prioritize my messages so that more important messages arrive before less important ones?” Yet almost no one worries about that once they’ve actually used our software. The reason is that, in RTI’s broker-free peer-to-peer infrastructure, there are no intermediate message queues to prioritize in the first place.
Archive for the ‘Best practices’ Category
Reconsidering Your Priorities
Posted in Best practices on May 11, 2009 | Leave a Comment »
Be your support engineer’s best friend
Posted in Best practices, tagged Debugging on May 7, 2009 | Leave a Comment »
In my previous post, I detailed two resources for answers to commonly asked questions or to look up specific known issues. Of course that requires you to at last know what to ask or look for. Before getting there you probably want to find out more about how the middleware is doing, or in the [...]
Throughput Performance: Comparing Apples to Apples
Posted in Best practices on May 5, 2009 | 2 Comments »
When evaluating vendors’ reports of throughput performance, it’s important to pay attention to the data size, system architecture, and testing methodology. Without an understanding of these things, you won’t be able to determine whether the reports are relevant to you or to compare different middleware implementations.
Solutions! Solutions! Solutions!
Posted in Best practices, Product news, tagged Debugging on May 1, 2009 | Leave a Comment »
Leading the support team at Real-Time Innovations, I get to experience first hand how our customers are using our middleware. The type of questions range from simple how-to questions to more involved inquiries on recommended ways of implementing a particular communication pattern. And of course there is the occasional defect. In my maiden blog post [...]
Data Transparency: Why You Should Care
Posted in Best practices, Standards on April 30, 2009 | 2 Comments »
Supreet had a great post recently about the importance of giving your data model significant design attention, just as you do your system’s performance, determinism, and functionality. (Indeed, you can hardly separate these things.) I’d like to take that theme a bit further, and talk about some of the things RTI Data Distribution Service can [...]
Is Physics holding you back?
Posted in Applications, Best practices on April 28, 2009 | Leave a Comment »
One of the more interesting aspects of distributed application development is to be aware of the physics involved in the deployment. Any signal experiences a propagation delay resulting from the finite speed of light, which is about 300,000 kilometers per second, or 1 nanosecond per foot. While getting a faster middleware such as RTI Data Distribution Service is part of the solution, the comprehensive way to address this issue is by distributing the intelligence in the network.
Designing information models for distributed applications
Posted in Applications, Best practices, Future directions on April 20, 2009 | Leave a Comment »
The technologists in edge environment spend significant time tuning the network links, but they often miss opportunities to make optimal use of available bandwidth by not focusing (enough) on tuning the data model. This (relative) lack of attention to the data model, while regrettable, can be better understood if we account that until recently, edge devices were weak (could not collect or process enough information), few (not choking the network, though bandwidth is always an issue), or not (richly) context-aware (taking advantage of other information available on the network) The science of tuning the information model for a distributed application can benefit from the advances in building information models for the enterprise applications.