title: Protocol architecture for communication between embedded device and remote server
body: <p>I have few questions about the best protocol architecture for a specific application. Let me explain better my application.</p>
  
  <p>In my application, there are 3 elements:</p>
  
  <ul>
  <li>Meter</li>
  <li>Concentrator</li>
  <li>Server</li>
  </ul>
  
  <p>The meter (an embedded device) sends messages, periodically, to the concentrator (another embedded device) through a RF link. In this communication we are using the WM-Bus protocol and I don't have any problem.</p>
  
  <p>The concentrator communicates, every day, with the server to transfer data collected from the meters during the day. This data can be different kind of data, such as, readout data, alarms etc. and it's possible one day the concentrator has just the readout data to be transferred and, in another day, a lot of different kind of data. In addition to this situation, sometimes, the server needs to send data to the concentrator, for example, when the server wants to change concentrator's configuration. This connection will be handled by GPRS module which has the TCP/IP implemented, therewith, low-level protocol is not a problem. The protocol which will be used in this part of the system will be a proprietary protocol and we are having problem to specify it.</p>
  
  <p>We thought two possible architecture for this protocol. 
  The first option, the server is the master (server) of the communication and the concentrator is the slave (client). In other words, the server opens a listening socket and wait for the concentrator's connection. When the concentrator opens a socket with the server, it sends its status word (bit field) which, each bit, indicates the reason of the connection, then the server starts to ask the data through specific commands.</p>
  
  <p>In the second option the concentrator is the master. In this way, it opens a socket with the server and sends the data using specific commands. In my option, this option sounds better, because the concentrator knows which kind of data it needs to send and do it, instead of the first option where the server needs, first, to see the status word to decide which data it has to ask. In this architecture, although the concentrator is the master, it's still a client in the client/server model, because it's the server which opens a listening socked.</p>
  
  <p>My doubt is which is better, the server behaving like a system that obey the concentrator or vice versa.</p>
  
  <p>The concentrator is a ARM Cortex-M3 microcontroller and will be programmed in C language. The server will be in Java.</p>
  
  <p>The architecture should be robust, because one server can be connected with 10K of concentrator and each concentrator can be connected with about 200 meters. So, indirectly, the server will receive data from 2 millions of meters.</p>
  
  <p>Which architecture is more indicated for my application? Why? </p>