InitRech 2015/2016, sujet 23 : Différence entre versions
m (→Summary) |
m |
||
Ligne 31 : | Ligne 31 : | ||
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. | 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 use to | ||
+ | |||
+ | |||
+ | Miniweb and µIP are the 2 others Emebedded web servers use for the comparaison. | ||
+ | THey show us that Miniweb is just able to use static files and µIP use more memory | ||
+ | thanks to the protothreads. | ||
+ | The comparaison pose in light that Smews is more effcient than the 2 others (except for static file | ||
+ | on Miniweb and its not far away). | ||
+ | |||
=Applications= | =Applications= | ||
applications découlant de l'article en une vingtaine de lignes. | 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. |
Version du 17 juin 2016 à 16:18
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 sigle 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 use to
Miniweb and µIP are the 2 others Emebedded web servers use for the comparaison.
THey show us that Miniweb is just able to use static files and µIP use more memory
thanks to the protothreads.
The comparaison pose in light that Smews is more effcient than the 2 others (except for static file on Miniweb and its not far away).
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.