Helsinki, Finland – October 21, 2009 – Meshcom Technologies today announced its latest contribution to the global open source community and wireless industry by releasing its previously proprietary Meshcom MeshDriver software as open source and now available to everybody. The software will be published available through EmbedOne, the open source division of Meshcom. Meshcom also announced the future development of MeshDriver will be EmbedOne community driven.

“MeshDriver can be implemented in any Wi-Fi device; from access points, networked surveillance cameras and laptops to smart phones, cameras and printers. It will provide ubiquitous connectivity and matches nicely with recent news from Wi-Fi Alliance announcement of Wi-Fi direct to enable peer-to-peer Wi-Fi connections. The solution enables users and devices to see the other users around and interact with them – or connect to devices through them – without any unnecessary configurations”, said Marko Nieminen, VP of Engineering at EmbedOne.

MeshDriver is available for downloading to desktop and embedded Linux, as well as Windows operating systems. Users and developers can find the source code, discussion forums and related development tools available from EmbedOne community starting from today at http://embedone.com

“Our goal is to fuel the creativity of developers for networking and connectivity applications. The idea of making MeshDriver open source has been bubbling in our minds for some time now and the idea supports greatly our goals. Now, it seems that Wi-Fi is developing to the direction with great potential for totally new revolutionary applications and therefore supports our mesh vision very well. Since the launch of EmbedOne, the open source division of Meshcom, we have been preparing MeshDriver for open source distribution and today we are happy to announce it is officially available”, said Miska Kaipiainen, CEO & Founder of EmbedOne.

What does it do? According to Wi-Fi Alliance, it will finally allow direct connections between any Wi-Fi devices. It will be replacing the Ad-Hoc mode which has suffered from poor usability, interoperability and data rates, without any decent security.

Wi-Fi Direct will support all available data rates, up to ones supported by 802.11n, as well as WPA / WPA2 security. This new technology can be implemented in any Wi-Fi device, from mobile phones, cameras, printers, and notebook computers, to human interface devices such as keyboards and headphones. According to Wi-Fi Alliance, the interoperability testing of Wi-Fi Direct devices will start in mid 2010. Needless to say, this technology will shake the Wi-Fi access point market a lot. I must say all this sounds too good to be true. Finally Wi-Fi can provide the connectivity we have always been wanting. This may be the first real solution getting rid of all those Ethernet cables – How cool is that!

It will also impact our lives here at EmbedOne. We already have bag full of great features we can add to our EmbedOne Linux to take full advantage of the Wi-Fi direct whenever it becomes available for public. Looking forward at that!

Who is the loser? Bluetooth. Although, I can still see future for Bluetooth due to its lower power consumption (in comparison to Wi-Fi) in mobile phones and other ultra mobile communication devices. But in everywhere else, Wi-Fi Direct will be the winner, until something shiny and new is invented.

Wi-Fi Direct will also enable peer-to-peer in big scale (=mesh networking) finally to become reality. The biggest hurdle for us, and probably for anybody who has been working with mesh networking, has been the fact that currently there is no convenient way to do dynamic AP-AP and Client-Client connectivity. The only “universal” way for creating mesh networks has been exploiting and tweaking the Ad-Hoc mode to it’s max (both in Mesh APs and clients). Now, it seems that we can finally get a solution for connecting ANY Wi-Fi devices together and just apply mesh routing algorithm on top of that. For us, the timing for Wi-Fi Alliance to announce the Wi-Fi Direct technology is just great, because we have just a while ago made a decision to open source our m…. Oops, almost said it. I’ll talk about this more when it is official

What is the “cross-domain communication”?

There are quite a bit of information on the Internet about this particular notion, so in here we just summarize the concept. Domain is a set of ip-addresses. Modern Internet browsers allow to generate dynamic content. When content, that is being generated from one domain accesses data from another domain this is the cross-domain communication.

What is the problem?

Basically, the problem is that due to security reasons the modern browsers do not allow cross-domain communications.

In general, javascript has many tricks to manipulate the document location and to create new requests run-time. Unfortunately, all of those things as document.location, document.domain etc. are very well guarded by the browser, when it detects a cross-domain requests. Even more, it is not possible to access the document content, that is open in a frame, if the source is from a different domain. So, while web browser became a powerful platform that could be used to develop very nice web-applications that bind services from different providers together, currently, there is no way to properly create HTML4 compliant cross-domain service.

But, hey! Google does it somehow! Can we hack around it?

Essentially, there are two approaches that could be used at the moment to overcome the browser guard. Both of these approaches do require a server counterpart, that is specially tailored for the application. The approaches are:

• Script insertion
• Auto-redirecting

Script insertion is based on a fact, that it is allowed to download a script from any given domain and there is mechanism to insert a new script into the document on the fly with immediate evaluation on the load. Auto-redirecting is based on the possibility of redirecting the page automatically when the page is being loaded. Both of these approaches have their benefits and drawbacks as we will see later.

JSONP (script insertion)

How does it work?

Lets assume, that we have a textarea iResponse and we want to set its value to something that we will receive from the server. And that we have some server in a different domain. With script insertion we can send a HTTP-GET request to the server like this:

function insertScript( url){
    var script = document.createElement("script");
    script.setAttribute("src",url);
    script.setAttribute("type","text/javascript");
    document.body.appendChild(script);
}

url in the request is a proper HTTP-GET request with the parameters. Hence server can receive input to work with. The trick with JSONP is how the output is passed back to the client. The newly downloaded “script” will be evaluated on load. Hence, if the script contains:

call_me( value );

A method call_me() will be called with the value as a parameter. Hence we should have another bit of script in our client to have a callback:

function call_me( vParam ){
        document.getElementsByName("iResponse")[0].value = vParam;
}

Finally, JSONP-based services are (if they are not tailored to a single client when the callback is predefined) should take the callback name as a parameter:

url = "http://dummy.server.org/Create_a_Script.php?callback=call_me&......

Looks nice! Why would we need anything else?

Unfortunately, there is a limitation. Besides some troublesome encoding, HTTP-GET request was not intended to sent large chunks of data. While the standard does not limit the potential length of the URL, there are very real limits imposed by servers, proxies and browsers. These limits are often due to the “common sense” approach to the software engineering. After all,

 “640K ought to be enough for anybody.” -Bill Gates (1981).

Never the less, we have seen that some browsers can dynamically create as short as 1k GET request. Meaning that it is only suited for a very limited data upload to the server with the standard JSONP approach. I know, I know… that is not much at all. So read the next section .

Using HTTP-POST cross-domain

It is possible to make a POST request cross-domain from a browser by submitting a form. However. it is not possible to use the answer, that you will receive in the context of the original document from which the original request was sent. So, any approach that would allow to send a POST data and to use it’s results have to be split into two stages: Send the Request, Retrieve the Result. The trick is how to make these two requests bind together automatically, without active input from the user (hence, some sort of dynamic content).

R-UI (remote UI on some server)

The R-UI approach is based on the automatic redirecting. It allows to send a HTTP-POST request to the server to pass the input parameters, and through the automatic redirect the document is returned to the original domain before it fetches the result. Lets assume that we have:

• An html form at address http://www.host1.com/emid-ui/form1.html
• An html at address that displays the result http://www.host1.com/emid-ui/res1.html
• Emid box at address http://10.0.0.1/emid

The communication algorithm will be the following:

• open form1 (domain: www.host1.com )
• submit the form -> http://10.0.0.1/emid. Append result page address as a parameter to the POST data. At this point browser will start retrieving the result from the emid box and change the document domain to 10.0.0.1
• The result comes in the form of a auto-redirect script

         <html>
         <head>
         <script type="text/javascript">
   function redirect_me(){
      document.location='http://www.host1.com/emid-ui/res1.html#requestID';
   }
         </script>
         </head>
         <body onLoad='redirect_me();'>
         </body>
         </html>

• After this script is loaded the redirect will start loading the result page from the www.host1.com. It will change the domain back to the original host. The resultID, passed as a anchor target, should be parsed onLoad and used to issue a JSONP request to the server to get the associated result

Problem with UI-R approach

Well, there is no problem with remote UI approach, unless you want to run the application from the local disk. Browser will simply forbid you to change the address back to file:///. Is there a walk-around? Yes – there is! Its in the next section.

The ultimate solution

Both JSONP and R-UI approaches are based on an assumption that there is a single request-response chain between the client and the server and all the states in the chain are visited exactly once during the request. Hence, there is a need to fit all the request parameters into a single GET request, etc. However, if the data submission itself will take place over a variable number of GET requests with each no more then 1000 characters long, then JSONP approach could be used to communicate any data across domains. However, the drawback is that the complexity of the server-side and client logic will grow dramatically. But it works well in different modifications. EmbedOne Web-Client, for example, feeds the data in parts to the server and then signals that the request is complete. Only after that server starts to process the request. As a result, reasonably large amounts of data could be sent in a report. The comparative table bellow shows all three approaches:

Is it the end?

Arguably, all of the above approaches are walk-around of the security mechanisms that browser developers create to protect the users from malicious content. However, the necessity to have proper cross-domain communications is obvious since many of popular services rely on those. As a result HTML5 specification provides another way to do controlled cross-domain communications by the means of window.postMessage(). But it is for the future…

Thumbs up ADI! This is a great offer! For anybody interested, please contact ADI Engineering to order kits and for more information on ADI’s Open IPcustomer engagement model.

The new EmbedOne Linux supported platforms are:

• ADI Pronghorn Metro
• ADI Pronghorn SBC-250
• Gateworks Avila 2348-4
• Gateworks Cambria GW2358-4

Please, see ADI Engineering and Gateworks websites for more info about these companies and to order their platforms.

EmbedOne EMI is embedded Linux OS management framework. It is a turn-key solution for embedded system developers and applications providers. It features unified management interface of system through JSON-RPC like API and extensive developer tools for own extensions. It can manage system configuration changes, system software updates and applications control. EMI is available under open source and commercial licenses.

EmbedOne Linux is new embedded Linux OS and development environment optimized for networking applications. Naturally, EmbedOne Linux is powered by EMI. In addition, it features new and innovative virtualized cross development environment enabling rapid application development with no need to invest in cross development environment. EmbedOne Linux is designed to cut time-to-market and development costs. It is open source and absolutely free.

In addition, EmbedOne announced availability of professional support and engineering services related to its new product offering.

“Embedded Linux has been coming for many years now and many companies have been mesmerized by its license free nature and the features it can provide – free of charge. However, the major breakthrough in embedded is still yet to come. We have noticed that many communities and organizations are struggling with their embedded Linux projects due to major integration issues resulting to delays in product roll-outs. We have spent past years in developing a solution to correct this major issue and today we are extremely happy being able to announce our solution that will benefit the embedded Linux community as a whole and especially companies who work in it”, says Miska Kaipiainen, CEO and Founder of EmbedOne.

• Technical Discussion and Insights – Latest news form our engineers, best practices, code snippets, and general technical information.
• Market Insights – Discussions of trends and opportunities in embedded development.
• Partner Announcements – Special promotions and news from our partners to EmbedOne community.

One of the important aspects of a great blog is the community engagement and we’re making that our primary focus for the EmbedOne Blog. We will, of course, respond to your questions and comments, but we’re also looking for you to share your experiences and insights with the rest of the community.

Post a comment and say hi! We look forward to hearing from you!