When your hunting tricky network bugs, its helpful sometimes to draw a map of where the bugs might be hiding. I had to do this to get the (last?) networks bugs which were hiding out in an involved service registration process. Added new feature to MRL too - the capability to spawn other MRL instances.
Hopefully I can put together a tutorial soon to show how to use all this new functionality.
Things still left to do :
- Dynamic network protocol assignment like UDP for Video & Audio streams
- Heartbeat for connectionless protocols like UDP
- Platform and type checking
- RoutingHistory implemented with different data structure - HashSet - and performance metrics added
- Switch for detailed Message logging
- SendBlocking timeout - must log error
- GUI shows duplicate in running services - for any new service created
- Ability to robustly shutdown an instance
- Multi-cast protocol - discovery !
- Add auto-connect option
- Ability to spawn new instance from the GUI (with options)
Finally squashed a very big network bug - I was not reseting the ObjectOutputStream after each message - this lead to the stream caching objects and no data transfered to remote clients. Finally ! This morning I tested 40 Clock clients - and it appeared to work ! Then for grins I went to 100 remote clients in the same star topology I previously tried. The "servers" gui was slow and crashed after all 200 tabs came up. I think this is progress ? :) . There are still a couple threading issues in the gui... I'll get them one of these days. On a different test I decided to try something much more data intensive - video streaming (no control over this). I had a few problems getting a system up initially - it seems the streams become corrupt at some point. But I did have success in one test with 5 clients ! 5 simultaenous video feeds to remote clients !!! - It lasted 5 minutes before one of the streams became corrupt.
Next on the agenda would be to add UDP video streaming (TCP is not as proficient). Also, I'll have TCP & UDP stream corruption issues reconnect & recover !
There are still some lingering bugs in networking, but it's getting a lot better. The above screen show's 10 instances of MRL all connected in a Star Topology to a single 11th Instance. This proof of concept might be for multiple raspberry pi's connected to a single instance so they cuold "work together" in a swarm.
In this example I created 10 instances, each with its own gui - (which is probably not what you would want on the raspberry, but it made it easy for me to see what was happening)
All these clients can be controlled by the 11th hub / master instace - To see cause and effect each rasPi instance has a clock, and I turned some of them on from the master instance.
Or this could be (N) number of Instances on (N) number of computers with (N) number of Arduinos, whatever :)
I still know of some bugs - but I'm getting closer to squashing them too !
Above you can see 2 instances of MRL connected together. One MRL instance will run on a RasPi - but currently I have it running on a laptop with another MRL instance.
Some things to note:
I've changed the names via the startup scripts so they don't clash - Remember, its one very imporant thing in MRL - "no 2 services can be named the same thing" .. You can change the names on the command line.
This is the command line in the myrobotlab.bat file
They initially tell one another about themselves - and "register" their services - When a service gets registered in a system which contains the GUIService - a GUI is created.. and Viola - you can control one from the other..