On Tuesday we tested the SRConsole application for receiving data by using a small HTTP test program I wrote which simply sends a string using the HTTP client component. Using data generated by the Model program, we were able to successfully deliver the data and the components updated properly. So this means that the issues when running directly between the model and console are sourced in the model application. I made a change in the port numbers so that I could run both programs on the same machine and was able to load both programs in individual debugging sessions.
When the data is sent it looks fine but somehow the various characters are getting translated into URL encoding format using the HTTP client. So a different direction was in order. HTTP uses TCP. This means that a target machine must be known to send a message. To get this to work in the push model, the client must send a message to register itself so that the model program can send data. This poses potential issues if the console program fails to unregister when it exits.
However the Indy package also provides both client and server UDP components. UDP is a connectionless protocol. Packets are sent on the wire and if the target program is listening then it will get the message otherwise the message is just ignored. It is possible to direct the packets to a specific machine, however it is also possible to broadcast the packet so that any program listening on that port will receive it. In this case it is perfect for distributing data to multiple consoles running on various machines. If all of the consoles listen on the same port it is possible to send one message and have it picked up by all listeners. This will actually reduce the overall network traffic since the message is only sent once and not repeated for each console.
The good news is that the Indy UDP components worked flawlessly. The data came across without any problem, and the controls were properly updated. The only issue that will have to be watched is that the UDP packet size is limited to a finite setting. This puts a limit on the amount of data that can be sent in one message. (Currently the limit is set to 8KB). XML is often wordy when the tags are appropriately descriptive. I am not sure what the actual limit is on packet size. If I find one then I may have to split the data into multiple message. (I can also abbreviate the tag names for a pretty good reduction in the XML size).
Now that the data is coming across I can see that I need to normalize the values to reasonable scales. If possible I will represent things in percentages. These tend to be easier for people to intuit. So I need to scale the values into the 0..100 range. Most of the gauges and dials are defaulted to that range anyway. More on this in the next post…
- Charlie's blog
- Log in to post comments