InitRech 2015/2016, sujet 23 : Différence entre versions

De Wiki d'activités IMA
m (Main Contribution)
m (Main Contribution)
Ligne 30 : Ligne 30 :
 
The authors propose an architecture that can handle simultaneous connections. Smews is designed to use a single shared buffer so only one information is processed at a time. Smews share information between the IP Stack and the application for an improvement of performance. For the same goal, Smews does not waiting the acknowledgement for static file like a traditional TCP stack. It retrieve data in case of retransmission and defined shared buffer is provided to transmit server-side generators.
 
The authors propose an architecture that can handle simultaneous connections. Smews is designed to use a single shared buffer so only one information is processed at a time. Smews share information between the IP Stack and the application for an improvement of performance. For the same goal, Smews does not waiting the acknowledgement for static file like a traditional TCP stack. It retrieve data in case of retransmission and defined shared buffer is provided to transmit server-side generators.
 
As a result this server is able to have several in-flight packets for most of the Web contents it serves and have large MSS size handle even with a small sized buffer.This architecture can use standard file like html, css, js and some native code.  
 
As a result this server is able to have several in-flight packets for most of the Web contents it serves and have large MSS size handle even with a small sized buffer.This architecture can use standard file like html, css, js and some native code.  
Miniweb and µIP are the 2 others Embedded web servers use for the comparison. They show us that Miniweb is just able to use static files and µIP use more memory thanks to the protothreads.
+
 
 +
Miniweb and µIP are the 2 others Embedded web servers use for the comparison. They show us that Miniweb is just able to use static files and µIP use more memory thanks to the protothreads it use to handle the TCP connections.
 
The comparison sets out that Smews is more efficient than the 2 others explained with their architecture designed for minimal shared content.
 
The comparison sets out that Smews is more efficient than the 2 others explained with their architecture designed for minimal shared content.
 
In Smews, OgO files and static web files are preproceed to create C content. The compiler generates the binairies from C files and S-S generators. This is the best way to incrust the static content into the hardware and save some memory.
 
In Smews, OgO files and static web files are preproceed to create C content. The compiler generates the binairies from C files and S-S generators. This is the best way to incrust the static content into the hardware and save some memory.

Version du 17 juin 2016 à 16:34

Summary

This paper discuss the technical feasibility of embedded Web servers and propose a solution for tiny devices such as Arduino or Funcard.

The number of devices running in our environment increase and the desire of connect all of them and do it with the minimum of program and memory is even bigger than 2009 (Date of the article). Smews is operating system desing to support both IPv4 and IPv6 ant to be used as an embedded web server. The project is under the CeCILL license and the program's sources are available on GitHub.This include the capicity to be recognized in a network and exchange with peripherals via the internet protocol TCP/IP.

The state of art show us that the internet of thing answer the quesion of the unvaibilty for the devices running around us to communicate. The well-known standard for this kind of system is the UPnP but this technology have several drawbacks like security or the unavailability to create hierarchical network. Because of the hardware constrained devices, it's important to keep in mind that the connexion are available in a little perimeter, the physical layer of this communication is therefore limited to (USB, Bluetooth, ZigBee...). Another technology which uses a non standard protocol is described by the authors and could be use on tiny hardware constraint devices. The JXTA is mentionned for its capability to be run on this kind of hardware, instead of the the successor of the UpnP : DPWS. This last one have bigger memory and cpu usage need but include a secure authentication system. To understand the dilemma, the authors described the actual design of the Web of Things, by explaining the AJAX model (Asynchronous JavaScript and XML)

This web design is done in two phase :

  • The reception of static files (HTML, CSS, Javascript).
  • The execution of the files get in the first phase and the asynchronous exchange between server and user.

This methodology reduces web traffic because "dynamic content are semantic information and the formation rules are loaded only once in the initialization phase." But if we dig even deeper the protocol uses to discuss are running in a different way and allow multiple request in short time. Like the IP/TCP, uses to communicate in a network, is running on this way, and is a problem for our tiny device with few Mhz frequency and kilo byte of memory. This paper claim a Personal Area Network (PAN) wherein tiny devices can easily discuss. A user (standard web browser) with more power than our peripheral can be running and do an more complicated execution. This is the main goal of the Internet of thing. The capabilty to tiny devices to discuss, interact without user activity via the conception of this macro-kernel named Smews.

This state of art is the beginning for our contributors and expose the problem by replying it.

Main Contribution

The authors propose an architecture that can handle simultaneous connections. Smews is designed to use a single shared buffer so only one information is processed at a time. Smews share information between the IP Stack and the application for an improvement of performance. For the same goal, Smews does not waiting the acknowledgement for static file like a traditional TCP stack. It retrieve data in case of retransmission and defined shared buffer is provided to transmit server-side generators. As a result this server is able to have several in-flight packets for most of the Web contents it serves and have large MSS size handle even with a small sized buffer.This architecture can use standard file like html, css, js and some native code.

Miniweb and µIP are the 2 others Embedded web servers use for the comparison. They show us that Miniweb is just able to use static files and µIP use more memory thanks to the protothreads it use to handle the TCP connections. The comparison sets out that Smews is more efficient than the 2 others explained with their architecture designed for minimal shared content. In Smews, OgO files and static web files are preproceed to create C content. The compiler generates the binairies from C files and S-S generators. This is the best way to incrust the static content into the hardware and save some memory.

Applications

applications découlant de l'article en une vingtaine de lignes.

So this device can have multiple application. The ease to mixed with the coast of this kind of board allows a large public. The advantage of Smews is mobility, mixed with a certain speed. The first application that I think is to be independant of the network. Think you are not under your Wifi, or 3/4G connection and you want communicate with devices like usual. Start of this you can develop, work server when you are on travel with collegue or make a Tricount for spare the bill with friend.

For Private Local Communication, Smews can be accessed if we suppose a wireless communication in little perimeter. This oblige the user to be near the source and could be an advantage. Suppose that this web server is also the way to create a local ChatRoom, and more large a Local Social Network.

Of course all the domotic application are able but we don't use the advantages of its mobility.

But with the Funcard it could be also possible to reduces the number of card in porte monnaie. Via a Web browser we could be able to "configure" our card to be used as a Credit card or Social Security card.