   HLA vs Protocol Buffer
  Hi :)I'm currently reviewing possible communications' layers between distributed simulation systems and it seems HLA (high level architecture) such as Portico and CERTI are the defacto standard.Then I've noted that Google's Protocol Buffers can serve a similar function: both systems make use of a common type definition to encode and communicate data.I suspect Protocol Buffers are more efficient - though haven't tried.What are the differences, strengths and weaknesses of HLA vs Protocol Buffers?thanks :)   
  Protocol Buffers is serialization library. It takes a set of data and encodes it into a sequence of bytes or vice versa.HLA gives you framework that handles all the networking, data replication and propagation, persistence, logic, timing, redundancy, ....In short, serialization is just one of technical aspects involved in distributed applications.   ;  True - but, really underneath it all, they do the same thing.HLA provides ownership, timing and distribution mechanisms as well - but the core reason is that you want information to get from one system to another.Protocol Buffers do the same core thing - they need to be strapped to some TCP/IP service, but they're simpler and more efficient.Where is the determinant trade-off? Is HLA still smart in a highly distributed system that is time critical? What if high throughput is more important than meta-controls?;  I missed that all you need is data transfer (between, I assume, existing systems).If you have existing systems, then all you do need is serialization, since you already have a HLA (yours).If you don't, then it depends on many factors, mostly the total cost of rolling your own vs. using existing one.So to correct myself:Quote:What are the differences, strengths and weaknesses of HLA vs Protocol Buffers?Look at the APIs, and decide which works better for you.Scientific or open formats tend to be more available. Google on the other hand may stop working on PB tommorow. Another factor to consider is that scientific community will not touch anything commercial - so if you're working with scientists, you're almost guaranteed to not be able to use Google's products (most of the time).Quote:I suspect Protocol Buffers are more efficient - though haven't tried.They get 2 miles per gallon.But seriously, PB is serialization framework for run-time describable data. That determines the efficiency of algorithms. If data were hard-coded at compile time, it would use less memory and less code to process, but would be less flexible.Another factor to consider is data encoding. Typically, text representation is easier to maintain, whereas binary encoding uses less space, is slightly faster to process, but is inevitably bound to machine processing. Linux for example uses nothing but text files, even though they could be considered inefficient for the purpose of machine processing.Quote:Quote:Where is the determinant trade-off? Is HLA still smart in a highly distributed system that is time critical? What if high throughput is more important than meta-controls?Depends how far you push it.For extreme cases, you will not want any encoding, but will share memory itself. Data alignment and CPU/compiler compatibility becomes an issue, so do many more optimizations.Throughput starts becoming a problem once you try to saturate gigabit network. Google's MapReduce for example is "very inefficient", yet completely scalable over arbitrary number of redundant commodity machines.Until you have some use cases with real data, discussing real efficiency is mostly unproductive.   ;  Can't really discuss much exact implementation - mostly because I'm not told either. Damn militaries.... :PThe real problem here is extreme open-endedness on the one hand, and extreme performance driven focus on the other. The core is a tactical simulation (think real time strategy gaming, but for military evaluation purposes - scenario testing, doctrine development, etc). This requires vastly more resources than actual games since many complex AIs in very elaborate scenarios need to be resolved - and everything needs to be simulated 1000s times over. To get this going fast distributed and efficient systems are required.But. Also. They'd like to be able to hook up with other applications such as military flight-simulator training equipment and have the two/three/many interact with each other.