Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: Architecture Changes

  1. #1
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359

    Architecture Changes

    After some tough debate we have decided to implement some architecture changes to the OpenMobile framework. While this will slightly effect the compact monolithic design of the framework we feel the benefits will far outweigh the disadvantages.

    As of now Open Mobile is a single process that runs each plugin on a sandboxed thread to maintain stability and responsiveness. We are quite happy with the performance of keeping all communications in-process. However, in order to best maintain functionality on all target platforms we have decided to transition to a two process approach. While this does add some complexity to the design, this complexity should be transparent to both plugin designers and end users.

    The new two process approach will consist of the openMobile core process and a platform specific OS interface process (running as a service). Long story short...
    Advantages of the new design:
    • All unmanaged and potentially unsafe code (native calls) is now running in a separate process. Calls between the two processes use a message bus to prevent failure propagation.
    • If either process becomes unstable it can be restarted from the other further increasing the stability of the application as a whole (aka it would most likely take a hardware failure to cause a full software crash)
    • Only code specific to your operating system will be deployed saving space and potential confusion
    • Native interfaces will be much easier (and potentially more stable) to implement since there will be no cross-platform compatibility restrictions

    Disadvantages of the new design:
    • Message bus adds a tiny delay although testing shows this to be negligable
    • Complexity of running two processes instead of one


    Some techy details:
    • The message bus is being called U-bus and is a very lightweight binary UDP protocol (ports 8549 and 8550)
    • The Windows process will run as a windows service and interface directly with the windows API
    • The Linux process will be a GTK application running in the background and interfacing with dbus
    • The Mac application will likely be on hold until the first two services are created or until a Mac developer steps up

  2. #2
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    If either process becomes unstable it can be restarted from the other
    Reminds me of a story

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

  3. #3
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,560
    So is this kinda like a mythtv-like frontend/backend approach? What does this openMobile Core do? Are the plugins running as separate processes? I'm wondering how close far this design is from the nGhost3 design...

    Gary: my eyes glazed over attempting to read that "story". That and my ADD prevents me from reading something that long . I was like 4 years old in 1988, and I really never grew up.
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  4. #4
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by chunkyks View Post
    I had to go over that twice to figure out what you were going for lol.... Yea similar concept except without the security risk.

    Quote Originally Posted by kev000 View Post
    So is this kinda like a mythtv-like frontend/backend approach? What does this openMobile Core do? Are the plugins running as separate processes? I'm wondering how close far this design is from the nGhost3 design...

    Gary: my eyes glazed over attempting to read that "story". That and my ADD prevents me from reading something that long . I was like 4 years old in 1988, and I really never grew up.
    I knew you would jump all over that thought No its still a LONG way from nGhost but I think it gets the best from both worlds. Initially I was going to do an OSSpecificLib dll for each platform but after some trial and error found out that dbus callbacks wont work with winforms applications, and since there are no gtk apps for .net (only mono) I would need separate processes to hook dbus signals on linux. On windows, having message callbacks on a form that wasn't drawing has some obvious performance benefits along with the whole dual process stability thing.

    Plugins still run within sandboxed threads inside the core process. The core still contains pretty much the same stuff including all the controls, plugin routing and useful functions. The only difference is that things like wifi, disk insertion and volume change notifications will be passed to the core from a separate process. On windows this will also pass directshow notifications to the media player. On Linux, this will provide some dbus notifications to the respective media player plugins as well.

  5. #5
    licensed to kill - FKA kev000
    Auto Apps:loading...
    tripzero's Avatar
    Join Date
    Aug 2006
    Location
    16.40618, 120.61106
    Posts
    2,560
    Quote Originally Posted by justchat_1 View Post
    I knew you would jump all over that thought
    yeah, I'm a sucker for architecture discussions...

    No its still a LONG way from nGhost but I think it gets the best from both worlds. Initially I was going to do an OSSpecificLib dll for each platform but after some trial and error found out that dbus callbacks wont work with winforms applications, and since there are no gtk apps for .net (only mono) I would need separate processes to hook dbus signals on linux. On windows, having message callbacks on a form that wasn't drawing has some obvious performance benefits along with the whole dual process stability thing.
    Why don't dbus callbacks work with winform apps? You can use it without the gtk mainloop, you just have to call Bus.Iterate() on a timer or thread or something. I assume you tried using NDesk.DBus?

    Plugins still run within sandboxed threads inside the core process. The core still contains pretty much the same stuff including all the controls, plugin routing and useful functions. The only difference is that things like wifi, disk insertion and volume change notifications will be passed to the core from a separate process. On windows this will also pass directshow notifications to the media player. On Linux, this will provide some dbus notifications to the respective media player plugins as well.
    So the difference is ng3 system is a one to many process arch and openMobile is a one to one? And the reason you split them up is to take advantage of platform specific stuff like wifi, DeviceKit, etc?
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  6. #6
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    First things first.. HEY-O notifications are back!!!
    Quote Originally Posted by kev000 View Post
    Why don't dbus callbacks work with winform apps? You can use it without the gtk mainloop, you just have to call Bus.Iterate() on a timer or thread or something. I assume you tried using NDesk.DBus?
    Yea thats how its supposed to work but I've used exactly the same code with a winforms app and a gtk app and only the gtk app worked properly. When using bus.iterate() in a loop and tracing it, it does iterate every time a signal is raised but mono eats the notification with winforms so the callback is never fired.

    Quote Originally Posted by kev000 View Post
    So the difference is ng3 system is a one to many process arch and openMobile is a one to one? And the reason you split them up is to take advantage of platform specific stuff like wifi, DeviceKit, etc?
    Pretty much....we can fully sandbox each thread since its managed code, which gives the same stability benefit without the performance loss of interprocess coms (or at least thats the theory behind it).

  7. #7
    SuperMod - OBDII GPS Logger forum
    Auto Apps:loading...

    Join Date
    Mar 2009
    Location
    Los Angeles
    Posts
    929
    Pretty much....we can fully sandbox each thread since its managed code, which gives the same stability benefit without the performance loss of interprocess coms (or at least thats the theory behind it).
    Apart from the fact you probably meant "process" and not "thread" - IPC /a la/ dbus is *cheap*. IPC /a la/ sockets or even shared memory is even cheaper.

    In this day and age, I don't feel that that's a legitimate concern.

    The Linux process will be a GTK application running in the background and interfacing with dbus
    Why all this love for dbus? I just don't get why people like it.

    From a developer's perspective, it's *shameful*. If the API documentation tells you, in bold, that by using it you are "signing up for some pain", then perhaps, just perhaps, that's something of a red flag. Having used the dbus API, I hope it just curls up and dies. I realise that wrappers make it a lot easier, and are the recommended way of using dbus, but at some point one has to wonder if there aren't better options out there when the developers of the project tell you not to use it.

    Of course, if you've evaluated all of the RPC mechanisms out there and found that dbus works the best for your needs, then great. But by the sounds of it your needs include "cross-platform support", and apparently it doesn't actually work for you on windows.

    Gary (-;
    OBDGPSLogger, for logging OBDII and/or GPS data
    OBDSim, an OBDII/ELM327 software simulator
    mp3car forums: obdgpslogger, obdsim

  8. #8
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by chunkyks View Post
    Apart from the fact you probably meant "process" and not "thread" - IPC /a la/ dbus is *cheap*. IPC /a la/ sockets or even shared memory is even cheaper.

    In this day and age, I don't feel that that's a legitimate concern.
    Nope I did mean thread, even though its not a very common concept. Traditionally we think of processes sandboxed from the operating system. In this case we are actually sandboxing a thread. Any type of errors that occur within the thread is trapped locally, logged and then the thread is restarted. All interprocess coms go through a pluginHost which completes the barrier necessary to sandbox the plugins. Its a little bit odd but the results have worked perfectly so far.

    Well yes and no, dbus itself is cheap but any type of platform neutral IPC object passing is going to require passing pointers, which chances are will get very ugly when some of the developers around here try to use them. The goal here is to design a system thats (for lack of a better phrase) idiot proof.

    Quote Originally Posted by chunkyks View Post
    Why all this love for dbus? I just don't get why people like it.

    From a developer's perspective, it's *shameful*. If the API documentation tells you, in bold, that by using it you are "signing up for some pain", then perhaps, just perhaps, that's something of a red flag. Having used the dbus API, I hope it just curls up and dies. I realise that wrappers make it a lot easier, and are the recommended way of using dbus, but at some point one has to wonder if there aren't better options out there when the developers of the project tell you not to use it.

    Of course, if you've evaluated all of the RPC mechanisms out there and found that dbus works the best for your needs, then great. But by the sounds of it your needs include "cross-platform support", and apparently it doesn't actually work for you on windows.
    Personally i'm no longer a dbus fan but it is 100x better then the alternative in terms of development requirements. For example, I can fully interact with VLC using 20 lines of code. if I tried doing that with static calls it would be 10x that minimum plus the added trial and error of getting it working. Same thing for a dozen different system events which would require hundreds of lines of code along with hours and hours of reading up on the docs on each of the different libraries, it just makes sense.

  9. #9
    North of the land of Hey Huns
    Auto Apps:loading...

    Join Date
    Jun 2004
    Location
    Westminster, MD
    Posts
    2,144
    Quote Originally Posted by justchat_1 View Post
    Nope I did mean thread, even though its not a very common concept. Traditionally we think of processes sandboxed from the operating system. In this case we are actually sandboxing a thread. Any type of errors that occur within the thread is trapped locally, logged and then the thread is restarted. All interprocess coms go through a pluginHost which completes the barrier necessary to sandbox the plugins. Its a little bit odd but the results have worked perfectly so far.
    How is this different from traditional top-level exception catching? How do you stop a thread from loading something that potentially crashes it, therefore taking out the parent application if it's all in the same process?
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

  10. #10
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by malcom2073 View Post
    How is this different from traditional top-level exception catching? How do you stop a thread from loading something that potentially crashes it, therefore taking out the parent application if it's all in the same process?
    Two ways.... 1-we catch and eat the exception before it gets to the top level (and terminates the application) and 2-plugins do almost everything using the framework which handles a lot of the common mistakes. I should add not all of this is in the latest svn but its coded and working.

    Of course its not 100% crash proof, unmanaged code or api calls can probably take down the entire process, but we try to avoid that as much as possible. And now even if something like that happens, the background service can revive it.

Page 1 of 3 123 LastLast

Similar Threads

  1. Apple moving to INTEL
    By Hcomplyr in forum MacCar
    Replies: 45
    Last Post: 07-13-2005, 12:13 PM
  2. what does x86 mean
    By t0yrunner in forum Newbie
    Replies: 10
    Last Post: 02-13-2004, 08:27 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •