pile lwip et séquentialité

Bonsoir à tous.
Travaillant sur un projet académique sur les piles protocolaires pour les systèmes embarqués (je n'en suis pour le moment qu'à la partie bibliographique je suis trèèès loin d'avoir commencé le codage). J'ai cherché un peu partout les noms des piles qui existent (donc au passage si vous en connaissez, n'hésitez pas svp à partager ne serait ce que leurs noms, cela me sera TOUJOURS utile) il y a un nom qui revient assez souvent c'est la pile lwip (comme quoi c'est "la pile la plus utilisée pour les systèmes embarqués").
Honnêtement, j'ai encore un peu de mal à comprendre à 100% son fonctionnement (notamment savoir qu'est ce qui est configurable ou non dans une pile lwip?), la doc officielle d'Adam Dunkels est vraiment très incomplète à mon goût (donc là aussi, si vous connaissez un très bon article sur cette pile, n'hésitez pas à me l'indiquer). Bref, y a surtout un truc qui me dérange beaucoup c'est l'aspect séquentiel (ou non) de cette pile.
En fait, j'ai lu la doc officielle d'Adam Dunkels, et il y a une phrase qui me perturbe beaucoup :

Citation:

---

There are 2 ways of interfacing the TCP/IP stack, either calling the functions in the TCP/UDP modules directly, or using the lwIP API. The 1st approach is based on callbacks and an application program that uses this approach can hence not operate in a sequential manner. This makes it harder to program and the application code is harder to understand. Also, the application program that interfaces the TCP/UDP modules directly has reside in the same process as the TCP/IP stack. This is because a callback function cannot be called across a process boundary

---

Grosso modo, ils disent qu'un programme qui utilise une fonction de rappel "callback" ne peut pas fonctionner de manière séquentielle, j'avoue que je sèche ici et j'aimerai vraiment que quelqu'un m'explique ce point.
Aussi j'aimerai bien qu'on m'explique la dernière phrase, qui indique pourquoi le programme qui s'interface avec les modules TCP/UDP doit résider dans le même processus que le pile TCP/IP

Voilà, j'ai deux en priorité ces deux questions (surtout la première au fait!).
Sinon, -si c'est possible- j'aimerai bien que quelqu'un me dise juste les grandes lignes pour connaître d'une part les aspects configurables ou non de cette pile et d'autre part, quels autres piles existe-il pour les systèmes embarqués qui soient efficaces et très utiles.

Voilà, je crois que c'est tout, j'ai enooooormément de questions sur ce sujet (car il est très important dans le cadre de mes études et surtout parce que je n'ai pas beaucoup de connaissances là-dessus). Je me contenterai de ces questions en attendant d'éventuelles réponses.

Bien à vous

Bonjour,

Je n'ai pas travaillé avec lwip (qui est effectivement une pile open-source assez utilisée pour l'embarqué. IAR Workbench propose des exemples avec cette pile par exemple) mais avec la pile de Keil qui fonctionne avec des callbacks. En fait, la pile de Keil possède 2 API: une API type BSP avec des fonctions bloquantes. L'autre est une API non bloquante utilisant des callbacks.

L'idée est la suivante : soit tu fais connect() et tu attends que cette fonction retourne la main. Soit tu fais un connect_request(), cette fonction rend la main tout de suite et plus tard sera appelée ta fonction de callback pour te donner le résultat du connect() sous-jacent. Ce qui est expliqué que tu n'es plus en mode séquentiel mais en mode événementiel. Le flow de programme n'étant plus linéaire, c'est un peu plus compliqué à suivre.

Bonjour,

J'ai travaillé avec lwip.

Citation:

---

qui indique pourquoi le programme qui s'interface avec les modules TCP/UDP doit résider dans le même processus que le pile TCP/IP

---

Parce que la couche TCP/UDP partage le même espace d'adressage que la couche TCP/IP. Si tu n'a pas de MMU dans ton micro cela n'a plus d'importance.

Tu configure lwip directement à sa compilation en modifiant le fichier opt.h

Pour utiliser lwip en mode socket_api il te faut un petit OS.

Rebonjour à tous.
Je vous remercie pour les deux seules réponses que j'ai eu sur ce fil de discussion. En fait, avec du recul, ma question me semble bien plus abordable maintenant. Pour résumer un peu ce que j'ai trouvé, il suffit de constater que la programmation avec les callback s'appelle la programmation asynchrone (Asynchronous programing) et qui est opposée à la programmation séquentielle...

Passé cela, j'ai d'autres questions à poser sur la pile lwip (que je préfère regrouper dans un seul et unique sujet) car j'éprouve vraiment du mal à comprendre tous ses principes et je ne peux trouver de réponses concrètes et claires (ou des réponses tout court) à toutes les questions que je me pose (à cause entre autres du fait que je ne sois pas vraiment calé sur le côté réseau).

Parmi les questions que je me pose, c'est de savoir comment la pile lwip gère le multi threading (savoir s’il n'y a pas un thread bloqué + les problèmes de priorités) et savoir quels sont les aspects configurables de la pile lwip? (pour cette dernière, je n'ai pas encore reçu de réponse même si je l'ai posé sur la mailing list officiel des développeurs de la pile lwip, pour la suite, je vous recopie d'ailleurs un message que j'ai posté sur ladite mailing list).

Ensuite, en lisant la documentation officielle d'Adam Dunkels, la partie concernant le process model est sûrement la plus ambiguë pour moi. En fait, d'après ce que j'ai compris, le modèle de la pile lwip pourrait être modélisé comme suit : http://image.noelshack.com/fichiers/...sans-titre.png. Comme on dit qu'un bon schéma est mieux que 1000 discours, n'hésitez pas à corriger ma représentation si vous pensez qu'elle est erronée.
(je m'excuse pour la qualité du schéma, je l'ai réalisé avec paint)

- Comme vous pouvez le voir dans le schéma, "tous" les protocoles résident dans la même place : entre le haut niveau et le bas niveau. Et j'aimerai bien savoir si cette structure était statique ou bien on pouvait au contraire faire ressortir ces protocoles de ce schéma-là?
A cet effet, j'ai lu que la pile lwip étaient essentiellement conçue pour de petits OS qui ne supportent pas des "inter-échange" entre les processus. Si tel est le cas effectivement, je pense que la réponse à ma question est négative.

- Deuxièmement, et toujours à propos de la structure interne de la pile (pour savoir comment gérer les protocoles internes). Est ce qu'un protocole va avoir un seul service offert? Ou bien, ils peuvent offrir de multiples services (dans ce cas, comment modéliser tous ces services). Ensuite, comment donner un accès à un service qui est extérieur à la pile ? Enfin, est ce que les communications entre protocoles sont toujours bidirectionnels ou bien elles peuvent avoir une direction précise?

- Troisièmement, dans le bas niveau (qui est le niveau fournisseur), doit-on avoir un seul ou bien plusieurs points d'accès? C'est claire qu'on aura plusieurs points d'accès au niveau haut (car les protocoles proposent différents services), mais que peut- on dire pour le bas niveau?


Voilà, c'est tout. Je remercie d'avance toute personne qui a pris la peine de lire mon message!
Bonne fin d'aprèm

Citation:

---

- Comme vous pouvez le voir dans le schéma, "tous" les protocoles résident dans la même place : entre le haut niveau et le bas niveau. Et j'aimerai bien savoir si cette structure était statique ou bien on pouvait au contraire faire ressortir ces protocoles de ce schéma-là?

---

??????? Faut regarder le code de la lwip.
Je n'ai travaillé qu'en mode socket, et dans ce cas la c'est difficil et RISQUé d'aller voir ce qui se passe dans le couches inférieures.

Citation:

---

Ensuite, comment donner un accès à un service qui est extérieur à la pile ?

---

voir POSIX socket

Citation:

---

Troisièmement, dans le bas niveau (qui est le niveau fournisseur), doit-on avoir un seul ou bien plusieurs points d'accès?

---

Dans mon cas (Xilinx) il faut déclarer/rajouter les interfaces réseaux (controleur ethernet) dans l'initialisation de la pile

lwip_init();
xemac_add(nwif,&ipaddr, &netmask, &gw, mac, XPAR_AXI_ETHERNETLITE_0_BASEADDR)

ou
-nwif est une struct netif *
-XPAR_AXI_ETHERNETLITE_0_BASEADDR l'adresse du contrôleur Ethernet.
-xemac_add est une méthode fournie par Xilinx.

- Tu peux m'expliquer stp vaguement comment les sockets POSIX peuvent être utile pour assurer un accès à un service extérieur à la pile?
- Aussi, tu peux être plus explicite quant u fait de dire que c'est difficile et surtout "risqué" de chercher à comprendre ce qui se passe dans les couches inférieurs? Car (pour le moment) c'est ce qui m'intéresse plutôt et au moins dans ce cas quand je devrai passer au code, je saurais ce qu'il ne faut pas faire pour éviter les conneries

Merci.

Citation:

---

- Tu peux m'expliquer stp vaguement comment les sockets POSIX peuvent être utile pour assurer un accès à un service extérieur à la pile?

---

Voici un super tuto dont je me sers toujours:
http://broux.developpez.com/articles/c/sockets/

Que cherches-tu à faire exactement ? Une application qui fait des sockets et des datagrammes ? Autre chose ?

Le modèle en couche d'une pile réseau (voir modèle d'OSI) te dit que tu n'as pas à regarder les couches internes quand tu utilises une couche de haut niveau. Savoir comme TCP passe à IP qui passe au PHY, ce n'est pas ton problème. Donc si tu souhaites te placer dans la couche application (au dessus de TCP), alors la mécanique interne exacte ne te sert pas. Tu peux vouloir l'appréhender pour ta culture personnelle. A ce moment là, renseigne toi "simplement" sur le modèle d'OSI et tu auras déjà un bon paquet d'info.

Bonjour à tous,
Travaillant toujours sur le même sujet (une pile de protocole embarquée), mon encadrant m'a demandé de lui faire un schéma XML d'une pile protocolaire .
Ainsi, la pile protocolaire serait simplement le fichier XML correspondant à ce schéma XML.

Est ce que vous pouvez m'eclairer un peu plus SVP sur ce sujet, ou au moins le point de départ pour pouvoir réaliser un tel schéma, parce qu'honnêtement je sèche beaucoup là-dessus!

Je vous serais éternellement reconnaissant si vous m'aider à débloquer cette situation car elle bloque carrément tout mon projet...
Cordialement

XML ou UML ?

non non je parle bien de XML et pas d'UML.
Je dirai plutôt, la notion de "méta-modèle" me semblerait plus utile dans ce cas, mais je sèche toujours pour pour pouvoir le réaliser.
Sinon, je réitère bien que mon encadrant m'a bien demandé un schéma XML (c'est pour cela que j'ai dis que la pile 'deviendrait' donc un fichier qui répondrait aux exigences du schéma XML). Je sais que ce n'est absolument pas claire, moi même je me sens hyper perdu...