Was genau ist ein Stack?
Ich höre es immer wieder, habe auch schon viel gelesen, kann mir aber
trotzdem nichts darunter wirklich vorstellen.
Z.B. ein CAN-Stack.
Wenn ich das richtig verstanden habe, ist ein CAN-STack quasi nur
Software (also Hardware unabhängig), eine art API. Man sagt z.B.
CAN_INIT(PRIO, NAME)
und der stack initialisiert dann den CAN (setzt Baudrate, setzt die
IDs).
Sendet, empängt NAchrichten, Fehlerauswertung usw..
Aber was ist dann der Unterschied zu einer lib?
Also ich könnte ja auch die Funktionen in einer Lib packen und hätte
quasi das selbe.
Gleiches gilt ja auch für Bluetooth-Stack und weitere.
"Stack" heißen die Teile wohl deshalb, weil sich da in der Regel auch in
der Software das ISO-Schichten-Modell einigermaßen abbildet, d.h. du
hast eine Applikation, die ruft die Netzwerkschicht, die wiederum ruft
die Transportschicht etc.
In der Praxis verschmelzen da oft einige Teile, aber eine gewisse
Schichtung ist in der Regel dennoch erkennbar.
Jörg W. schrieb:> In der Praxis verschmelzen da oft einige Teile, aber eine gewisse> Schichtung ist in der Regel dennoch erkennbar.
Dann kann man sich das doch so ähnlich wie eine library vorstellen?
In dieser sind dann noch mal schichten, bis zum versenden der NAchricht
(beispeil vom CAN)
Jens schrieb:> Dann kann man sich das doch so ähnlich wie eine library vorstellen?
Du vegleichst da Äpfel mit Gewässern.
Libraries sind Sammlungen von Funktionen, die man in Programme
einbindet. Das hat mit Stacks (aufeinander gestapelte Ebenen der
Software-Architektur) gar nichts zu tun.
Außer das Libraries Stacks und Ebenen enthalten können - aber eben nicht
müssen. So wie man Äpfel in Gewässer werfen kann, muss man aber nicht.
Nicht jede Bibliothek enthält einen Protokollstack.
Nicht jeder Protokollstack ist in Form einer Bibliothek aufgebaut.
Es gibt Bibliotheken, die vollständige Protokollstacks enthalten. Es
gibt Bibliotheken, die Teile eines Protokollstacks enthalten.
Protokollstacks können ganz oder teilweise in Form von
Software(-bibliotheken) implementiert sein. Protokollstacks können aber
auch ganz oder teilweise in Form von Hardware oder programmierbarer
Logik implementiert sein.
Entgegen vielfältiger Darstellungen müssen Protokollstacks nicht dem
OSI-Schichtenmodell entsprechen bzw. durch dieses darstellbar sein.
Es handelt sich eben um komplett unterschiedliche Betrachtungsweisen.
Jens schrieb:> Dann kann man sich das doch so ähnlich wie eine library vorstellen?
So wie man heute Librarys definiert (denke da ans Arduino Umfeld), würde
die Library einen CAN Stack enthalten.
Du rufst nur noch Init(); Send(xyz); auf, der Rest passiert unter der
Haube.
Dein Programm hätte dann einen CAN Stack, von dem du aber nix
mitbekommst oder irgendwie in eine Zwischenschicht eingreifen könntest.
Etwas anders wäre das, wenn du den Stack selber baust. Also eine
"Library" für das Hardware Interface an einen Puffer flanschen, da dann
irgendein Protokoll drüber bauen, Fehlerbehandlung durchreichen, ...
Andreas S. schrieb:> Nicht jede Bibliothek enthält einen Protokollstack.>> Nicht jeder Protokollstack ist in Form einer Bibliothek aufgebaut.>> Es gibt Bibliotheken, die vollständige Protokollstacks enthalten. Es> gibt Bibliotheken, die Teile eines Protokollstacks enthalten.>> Protokollstacks können ganz oder teilweise in Form von> Software(-bibliotheken) implementiert sein. Protokollstacks können aber> auch ganz oder teilweise in Form von Hardware oder programmierbarer> Logik implementiert sein.>> Entgegen vielfältiger Darstellungen müssen Protokollstacks nicht dem> OSI-Schichtenmodell entsprechen bzw. durch dieses darstellbar sein.>> Es handelt sich eben um komplett unterschiedliche Betrachtungsweisen.
Also ein Stack kann demnach auch unterschiedlich sein. (Das macht die
ganze sache nicht einfacher).
Aber z.B. die Implementierung eines Handshakes, Fehlerbehandlung,
allgemein senden/empfangen kann durch ein Stack erstellt werden, was
auch nciht in der Applikation aufgerufen werden kann.
Dort wird nur z.B. sendeDaten() aufgerufen. Und der STack kümmert sich
darum, dass alles richtig abläuft.
Heißt auch, dass die Applikation nach sendeDaten() normal weiterlaufen
kann (wenn so implementiert) und der Stack dann sendet und überprüft ob
gesendet worden ist wenn der bus frei ist
Andreas S. schrieb:> Entgegen vielfältiger Darstellungen müssen Protokollstacks nicht dem> OSI-Schichtenmodell entsprechen
Das OSI-Modell ist ja auch nur ein Modell, welches die grundlegende
Schichtung in der Kommunikation zu abstrahieren versucht. Es ist kein
Dogma. ;-)
Jens schrieb:> Andreas S. schrieb:>> Es handelt sich eben um komplett unterschiedliche Betrachtungsweisen.> Also ein Stack kann demnach auch unterschiedlich sein. (Das macht die> ganze sache nicht einfacher).
Das Problem ist, daß du zwei verschiedene Sichtweisen durcheinander
wirfst. Stack nennt man es, wenn man die logische Abstraktion in
verschiedene Schichten (Layer) hervorheben möchte. Das OSI Modell kann
man beispielhaft dafür ansehen, was für Schichten es geben könnte.
Aus Sicht des Anwendungsprogramms sind aber alle Schichten unterhalb der
Anwendungsschicht ohnehin unsichtbar. Die Dienste und Funktionen der
Anwendungsschicht stellt dann irgendein API bereit, für C typischerweise
in Form einer C Library, die Funktionen und Datentypen definiert und
implementiert.
Die tieferen Schichten des Stacks können Software sein oder Hardware,
Und wenn es Software ist, kann die in der gleichen Library stecken oder
in einer anderen. Oder vielleicht auch in einem Betriebssystem. Oder in
der ROM-Firmware des Controllers. Aus Sicht der Anwendung (und des
Anwendungsprogrammierers) sind das unwichtige Details. Wichtig ist nur,
daß alle Schichten des Stacks da sein müssen.
Was die Idee eines Stacks so sexy macht ist, daß man bei geeigneter
Unterteilung die einzelnen Schichten komplett unabhängig voneinander
implementieren und auch austauschen kann. Man kann bspw. den ganzen Teil
des CAN-Stacks oberhalb der Hardware (OSI Schicht 3 aufwärts) unabhängig
vom µC implementieren. Oder man könnte den Teil unterhalb austauschen
und statt eines physischen CAN Interface die Nachrichten in RAM-Puffern
hin und her kopieren und so zwei Prozesse auf dem gleichen Rechner so
miteinander kommunizieren lassen, als würden sie im CAN Netzwerk
verteilt laufen.
