mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Netzwerkstack im Eigenbau


Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
der Titel des Threads sagt es eigentlich schon, was ich tun möchte.
Der Grund dafür ist der folgende:
Zwar findet man im Netz sehr viele TCP-Stacks, doch möchte man etwas 
funktionierendes, kommt man nicht umhin, lwip oder uIP zu benutzen. 
Beide gefallen mir nicht, weil ich sie sehr unübersichtlich programmiert 
finde.
Des weiteren könnte man in lwip noch einiges Verbessern. Der Code 
unterstützt z.B. theoretisch mehrere Netzwerk-Interfaces. Doch wer hat 
schon mehr als eine LAN-Schnittstelle an seinem Mikrocontrollerboard? 
Das gibt also einen unnötigen Software-Overhead. uIP wiederum ist 
optimiert auf 8 Bit-Architekturen, und kann so einiges nicht. Hier ist 
man dann wieder zu eingeschränkt.

Mein Wunsch-Stack sieht so aus:

- IP
- UDP
- SNTP
- ist mit einem RTOS (z.B. uC/OS) benutzbar

Dabei möchte ich die Standards so weit es nur irgend möglich ist 
vollständig einhalten.
Jetzt die Frage:

1. Gibt es Leute, die Lust hätten, an dem Projekt mit zu arbeiten?
2. Wenn nicht: kann mir einer einen Anhaltspunkt geben, wo man am besten 
anfängt? ich habe schon so einiges gecodet auf meinem LPC2468 Board, 
aber so richtig zufrieden bin ich noch immer nicht damit.
3. Gibt es das, was ich mir wünsche, etwa schon? Bitte bitte nicht lwip 
und nicht uip. Die zwei kenne ich, und ich finde sie unschön :-(

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne TCP ist das ganze doch primitiv und nichts mehr als Auffüllen der 
Ethernet-IP-UDP Header und Berechnen der IP-Checksumme. Dafür brauche 
ich keinen Stack, das ist mit etwas Nachdenken an einem Nachmittag 
erledigt. Auch BOOTP/DHCP Client, TFTP, ARP und ICMP Echo sind 
eigentlich primitiv.

TCP ist das, wo die Komplexität drinsteckt und was Speicher braucht, und 
hier entscheidet sich die Qualität eines Stacks.

fchk

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>1. Gibt es Leute, die Lust hätten, an dem Projekt mit zu arbeiten?

Buhahaha.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank,
naja, als so trivial würde ich es doch nicht erachten. Schliesslich 
möchte ich mich schon an das OSI-Modell halten und die entsprechenden 
Teile genau so unterteilen, wie es eigentlich vorgeschrieben wäre. Wie 
wird z.B. ein IP-Paket reassembliert? Wie realisiert man den 
Datenaustausch zwischen dem Stack und den einzelnen Tasks des OS?
So einfach finde ich das gar nicht mal. Du kannst mir aber gerne einen 
Anhaltspunkt geben.

Autor: ikarus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> Schliesslich
> möchte ich mich schon an das OSI-Modell halten und die entsprechenden
> Teile genau so unterteilen, wie es eigentlich vorgeschrieben wäre.
Das OSI-/Referenz/-Modell ist keine Vorschrift, man nimmt sich heraus, 
was man braucht.
> Wie
> wird z.B. ein IP-Paket reassembliert?
Ist 'reassembliert' hier wirklich die richtige Vokabel?

Autor: Frank Morster (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> Schliesslich möchte ich mich schon an das OSI-Modell halten

Das ist eine blöde Idee, weil die Internet-Protokolle mit dem OSI-Stack 
nicht allzuviel gemein haben.

Tatsächlich bilden sie eine ganz eigene Schichtenarchitektur, die oft 
als "Internet Architecture" bezeichnet wird.

Die Abbildung auf OSI, die man öfter sieht, ist nur in allererster 
Näherung möglich.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ikarus,
im englischen heisst es reassemble (ich weiss nicht mehr, in welchem RFC 
es auftaucht, vielleicht RFC791 oder so...). Ich hab das einfach 
eingedeutscht ;)

Ich sehe schon:
hier scheint kein grosses Interesse an dem Vorhaben zu bestehen. Ich 
finde das eigentlich schade, denn heute tendieren die Leute immer mehr 
dazu, zu sagen "ach, das hat ja schon mal einer implementiert", dann 
wird als erstes gegoogelt, und der erstbeste Code genommen, der halbwegs 
läuft. Selber was zu machen hat offenbar niemand mehr Lust zu?
Da ist es ja kein Wunder, ist heute niemand mehr innovativ. Ich meine: 
schaut euch doch mal die Elektronikindustrie an. Die Geräte (egal welche 
Geräte) werdem immer schneller, kleiner und stromsparender, aber 
wirkliche Innovationen gibt es gar nicht mehr. Aber vielleicht könnte 
man diesen lwip noch ein bisschen besser machen, als er schon ist? Ich 
wundere mich, dass ich der einzige bin, der sich an diesem furchtbaren 
Programmierstil, der da gepflegt wird, ärgert.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> Frank,
> naja, als so trivial würde ich es doch nicht erachten. Schliesslich
> möchte ich mich schon an das OSI-Modell halten und die entsprechenden
> Teile genau so unterteilen, wie es eigentlich vorgeschrieben wäre.

IP wurde nicht mit Blick auf OSI entwickelt und hält sich selber auch 
nicht dran. Also brauchst Du es auch nicht zu tun.

> Wie
> wird z.B. ein IP-Paket reassembliert?

Meep. Falsche Frage. Fragmentierte IP-Pakete willst Du nicht haben. Die 
ganzen Standardprotokolle wie DNS und DHCP sind so gebaut, dass 
garantiert ist, dass sie nicht fragmentieren, denn es ist 
vorgeschrieben, dass die MTU mindestens 576 ist.

Bei Deinen eigenen UDP-Protokollen setzt Du einfach das DF-Bit. Wenn Du 
dann ein ICMP-Paket mit Typ 3 (destination unreachable) und Code 4 
(fragmentation required but don’t fragment bit set) bekommst, weißt Du, 
dass Du Deine MTU reduzieren musst.

IPV6 fragmentiert ohnehin nicht mehr.

> Wie realisiert man den
> Datenaustausch zwischen dem Stack und den einzelnen Tasks des OS?

Das darfst Du mit Dir selber ausmachen.

> So einfach finde ich das gar nicht mal. Du kannst mir aber gerne einen
> Anhaltspunkt geben.

Dein erster Anhaltspunkt sind die RFCs. Das sind die bindenden 
Dokumente.

fchk

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
schön, dass wenigstens du konstruktive Beiträge lieferst ;)
Ich mache das bei meinem Stack so:
Beim Initialisieren des Ethernet-Drivers wird ein Semaphor kreiert, 
welcher den Wert 0 hat. Beim Eintreffen eines Pakets wird dieser 
Semaphor jeweils um 1 inkrementiert. Mein Netzwerk-Task pollt nun diesen 
Semaphor, und wenn Pakete vorhanden sind (solange Semaphor > 0 ist), 
wird der netstack_process aufgerufen. Dieser kreiert einen Buffer, wo 
das empfangene Paket rein kopiert wird. Anschliessend wird mittels 
switc-case Konstrukten entschieden, ob das Paket dem IP- oder ARP-Modul 
übergeben werden soll.
Soweit so gut. Was hältst du von dem Konzept? Der Vorteil ist, dass, 
solange keine Pakete eintreffen, der Netzwerk-Task suspended ist, weil 
er ja auf den Semaphor wartet. Und wenn während der Bearbeitung eines 
Pakets weitere Pakete eintreffen, dann ist so sichergestellt, dass 
nichts verloren geht.
ARP habe ich schon implementiert und mich dabei streng an RFC826 
gehalten. Doch bin ich mir bei IP nicht mehr so sicher, wie ich genau 
vorgehen muss, wenn ein Paket eintrifft. Leider schweigen sich die RFCs 
darüber aus, in welcher Reihenfolge man was tun muss. Gibts da 
vielleicht so eine Art PAP oder so, wo das verdeutlicht wird? Oder 
implementiert das einfach jeder nach gutdünken?

Autor: Jörg Hermann (dr_coolgood)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias,

sind die Ergebnisse Deiner Recherchen wirklich nur uip und lwip? Was ist 
mit:

avrETH1 by Simon Schulz
avrfreaks by Jesper Hansen
AVRnet
etherrape by fd0 aka Alexander Neumann
ethersex by stesi
mega-eth by Roland Riegel
MicroWebServer by Simon Küppers
OpenMCP by Dirk Broßwick aka sharandac
Ulrich Radig
tuxgraphics by Guido Socher

Ich habe mir alle angeschaut. Fast alles deutsche Projekte, weil ich 
ausgehend von diesem Forum mit Fokus auf AVR gesucht habe. Die Welt wird 
noch ein paar mehr bieten. Bei anderen Architekturen kann man ja auch 
noch schauen.

Was wäre, wenn kompetente Mitarbeiter Deinen Programmierstil 
genausowenig mögen, wie Du den von Xip nicht? Will sagen, Du musst Dich 
den Gepflogenheiten eines Projektes auch unterordnen. Ansonsten fügen 
wir der Liste noch einen hinzu...

Womit ich sagen will: Nach meiner Meinung ist bereits zuviel Hirnschmalz 
redundant verschwendet worden, anstatt sich auf zwei, drei gute Stacks 
zu konzentrieren.

Anstatt den n-ten Stack zu entwickeln habe ich mich für einen aktiven 
entschieden und unterstütze diesen so gut ich das kann. Deine 
km-Leistung mag anders sein :-)

Viel Erfolg!

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sagte ja bereits, dass es eine grosse Anzahl von Stacks gibt. Doch 
habe ich mein ganzes Leben lang einen AVR noch nicht mal angefasst, ich 
kann daher die Funktionsweise von diesen ganzen AVR-Geschichten 
teilweise nur erahnen. Was meinst du mit km-Leistung?
Denkst du denn, es ist gar nicht möglich, einen eigenen Stack zu bauen?

Autor: Jörg Hermann (dr_coolgood)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias,

mein Standpunkt ist, dass ich gerne auf einem AVR programmiere, jedoch 
nicht alles.
Einen eth-Stack möchte ich als Modul benutzen, in der Liste finde ich 
jedoch 10. Zehn fähige Köpfe, die Header aneinanderfügen, Checksummen 
berechnen und letzten Endes das Gleiche tun: Ein Netzwerkpaket auf die 
Reise schicken.

Die Motivation für eine eigene Entwicklung statt Mitarbeit an 
bestehenden Projekten wird von Entwicklern meist beantwortet mit:
Weil man dadurch mehr lernt. Richtig! Und man macht auch mehr Fehler...
Womit der Anwender = ich sich dann herumschlagen darf.

Aus diesem Blickwinkel sind zehn verschiedene Stacks für mich 
verschwendete Ressourcen.

Sicher kannst Du Dich in diesen Entwickler-Reigen einfügen und Deinen 
eigenen Stack bauen. Die anderen sind auch ins Ziel gekommen, zum Teil 
ebenfalls als Einzelkämpfer. Allerdings verlängert Deine fehlende AVR 
Erfahrung die Lernkurve wesentlich.

Viel Erfolg!

PS: Die km Leistung ist der Versuch einer Eindeutschung von: Your 
mileage may vary.
Sinngemäss: Du magst unterschiedlich weit kommen, auch und weil Du evtl. 
einen anderen Weg wählst.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:

> wird der netstack_process aufgerufen. Dieser kreiert einen Buffer, wo
> das empfangene Paket rein kopiert wird. Anschliessend wird mittels
> switc-case Konstrukten entschieden, ob das Paket dem IP- oder ARP-Modul
> übergeben werden soll.

Kopieren ist doof, weil das CPU-Zeit kostet. Gute Stacks kopieren nicht, 
sondern halten Empfangspuffer vor, in die der Ethernettreiber die 
empfangenen Pakete reinschreibt.

Wenn Du nur auf ankommende Pakete reagierst, brauchst Du keine 
ARP-Requests, denn die MAC-Adresse bekommst Du ja geliefert, und dann 
reicht es, einfach im MAC- und IP-Header Empfänger und Absender zu 
tauschen.

> er ja auf den Semaphor wartet. Und wenn während der Bearbeitung eines
> Pakets weitere Pakete eintreffen, dann ist so sichergestellt, dass
> nichts verloren geht.

Das ist schön, aber der Standard erlaubt Paketverluste.

> ARP habe ich schon implementiert und mich dabei streng an RFC826
> gehalten. Doch bin ich mir bei IP nicht mehr so sicher, wie ich genau
> vorgehen muss, wenn ein Paket eintrifft. Leider schweigen sich die RFCs
> darüber aus, in welcher Reihenfolge man was tun muss. Gibts da
> vielleicht so eine Art PAP oder so, wo das verdeutlicht wird? Oder
> implementiert das einfach jeder nach gutdünken?

Du darfst die Freiräume, die die RFCs Dir lassen, nutzen. Entscheidend 
ist, was hinten rauskommt.

Und: Die Anforderungen haben sich in den letzten Jahren geändert. 
Einiges wie Type Of Service oder auch Fragmentierung wird heute fast 
nicht mehr gebraucht, weil es bessere Mechanismen (802.1p/q und Path MTU 
Discovery) gibt.

fchk

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in welchem RFC steht denn, dass man Pakete verlieren darf?
und ist es gemäss RFCs auch zulässig, fragmentierte IP-Pakete zu 
verwerfen?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe für meinen Webserver auch erst angedacht einen TCP/IP Stack zu 
schreiben. Und zwar wesentlich modularer, aber gleichzeitig viel besser 
geordnet als der uip (Alls in eine Datei gequetscht, goto's usw.). Dabei 
muss man nicht unbedingt die hohe Performance verwerfen, nur wenn man 
keine goto's benutzen will. Es gibt auch noch Sachen wie static-inline 
und gute Compileroptimierungen, sodass (Flag-)Variablen rausoptimiert 
werden.

Allerdings habe ich schnell die Lust dran verloren, denn:

* TCP/IP (also TCP über IP) ist erst undurchsichtig und nachher sieht 
man dann, dass es sehr viele Spezialfälle gibt, wann vorläufige ACKs 
gesendet werden etc. Und wenn man wirklich den kompletten Stack einbauen 
will, braucht man eben massig Speicher.
TCP/IP ist ja auch eher auf große Systeme heute angewendet. PCs mit 
Gigabytes an RAM. Bestimmte neue Features, die Paketprioritäten regeln. 
Die Liste geht ohne Probleme noch weiter. All das muss man sich 
durchlesen und u.U. sogar implementieren.

* Die RFCs sind schön und gut. Aber es gibt ziemlich viele, bzw. sie 
sind auch teilweise ziemlich lang, wenn man bloß die Grundfähigkeiten 
wie TCP, UDP, IP, MAC, ICMP einbauen möchte.

* Angenommen man hätte es geschafft alles zu integrieren, dann muss 
anschließend der ganze (mittlerweile verworrene Code) erst mal wieder 
aufgeräumt werden. U.U. Rewrite.

* Dann unter Umständen noch abstrahiert werden (mit defines). Also 
verschiedene Compile-Zeit Optionen einbauen.

* Das Alles dann noch mit jeder möglichen Option durchtesten.

* Und dann hat man nachher immernoch irgendwo einen kleinen Bug drin, 
der nur selten auffällt und schwer auszumachen ist (Fehler bei ACK/SEQ 
Nummern Berechnung, der nur auftritt, falls der Host mal ein "Bitte 
Warten mit weiteren Daten" (TCP mit Windowsize = 0, glaube ich) schickt, 
was eben nicht oft vorkommen wird).

Und noch ein paar Punkte mehr, sodass es sich einfach nicht lohnt noch 
mal etwas selber aufzusetzen. Da steckt schon eine große Zeit dahinter, 
bis sowas mal gescheit läuft. Selbst der Windows-XP Stack ist ja nicht 
ganz standardkonform. Wie es mittlerweile bei Windows 7 aussieht, weiß 
ich nicht.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon,
ja ich merke auch, dass es ein schwieriges Unterfangen ist. Dennoch 
möchte ich es gerne versuchen. Bei einigen Dingen, die z.B. in lwip sehr 
umständlich und unschön gelöst sind, fällt es mir sofort auf, wie man es 
besser machen könnte. Bei anderen Sachen wiederum hapert es.
Was mich beim lwip am meisten stört: der Quelltext ist enorm schwer 
lesbar, und die vielen gotos sind ziemlich unschön.
Mein Ziel ist es eigentlich, einen Stack zu bauen, der sich nicht nur 
durch eine gute Lesbarkeit auszeichnet, sondern ich möchte auch noch 
eine Doku dazu schreiben, damit auch ein Aussenstehender diesen ganzen 
TCP-Krempel verstehen kann.
Doch wie gesagt, vorerst ist noch gar nicht an TCP zu denken! erst 
müssen die ganzen anderen Schichten des Stacks Stück für Stück aufgebaut 
werden. Ich glaube mittlerweile, dass die eigentliche Schwierigkeit 
nicht in der Komplexität der ganzen Protokolle liegt, sondern eher in 
der Menge an Informationen, die man verarbeiten und lesen muss. Die 
ganzen RFCs, verstreut über hunderte von Dokumenten usw.
Dann noch die Frage, womit man überhaupt anfangen soll.

Dass das ganze massig Speicher braucht, ist mir klar, aber daran soll es 
nicht scheitern, denn ich habe genug Memory auf meinem Eigenbau-Board.

Frank,
dass Kopieren doof ist, sehe ich genauso :) nur geht es manchmal nicht 
anders. Beim LPC2468 gibt es einen Memory-Bereich, auf welchen per DMA 
zugegriffen werden kann. Der Ethernet-MAC platziert dann empfangene 
Frames automatisch dort hin. Da ich im Voraus nicht wissen kann, zu 
welchem Protokoll bzw. zu welchem Task ein empfangener Frame gehört, 
kann ich dem Ethernet-MAC auch nicht den Buffer angeben, wo er den Frame 
rein legen soll. Also wird erst mal alles in ein einziges grosses Memory 
platziert. Dieses Memory präsentiert sich der Anwendung dann als ein 
grosses Array von empfangenen Paketen, und mittels einer 
Zugriffsfunktion wird ein Frame nach dem anderen aus diesem Puffer 
geholt (natürlich über Pointer, um das Kopieren zu sparen).

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> in welchem RFC steht denn, dass man Pakete verlieren darf?

RFC791, Abschnitt 1.4:

  The internet protocol does not provide a reliable communication
  facility.  There are no acknowledgments either end-to-end or
  hop-by-hop.  There is no error control for data, only a header
  checksum.  There are no retransmissions.  There is no flow control.

> und ist es gemäss RFCs auch zulässig, fragmentierte IP-Pakete zu
> verwerfen?

(a) siehe oben
(b) Geht auch nur ein Fragment verloren, muss der Sender alle Fragmente 
neu absenden. Das ist ein Grund, Fragmente nicht zu benutzen. Zu der 
Zeit, als das RFC geschrieben wurde, gab es viele verschiedene 
Netzwerktechniken (X.25 via X.21, Token Ring, später FDDI, Arcnet,...) 
mit unterschiedlichen Paketgrößen, d.h. damals war Fragmentierung 
technisch notwendig. Heutzutage ist davon praktisch nur noch Ethernet 
übriggeblieben, und da braucht man nicht mehr zu fragmentieren. 
Ausnahme: PPPOE mit dem 8 Byte Header (Idioten, hätten die nicht einfach 
die Pakete wie bei 802.1pq um 8 Bytes größer machen können?)
(c) nur fragmentierte Pakete zu verwerfen ist sicher nicht im Sinne des 
Erfinders, aber Du kannst ja Deine Randbedingungen so wählen, dass sie 
eben nicht auftritt.

fchk

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
sorry dass meine Antwort so lange auf sich hat warten lassen.
Ich habe den Abschnitt auch grade gelesen. Nun weiss ich aber immer noch 
nicht, was ich tun soll, wenn ich ein Paket erhalte, wo das More 
Fragments-Flag gesetzt ist ;) am einfachsten wäre es schon, die Sache zu 
verwerfen.
Dann würde sich der IP-Layer relativ einfach gestelten. Bei Erhalt eines 
Pakets Empfängeradresse, Checksum und IP-Version prüfen, und anhand der 
Protokollnummer an den nächst höheren Layer weiterleiten.
So langsam habe ich schon die eine oder andere Idee, wie ich das machen 
könnte. Aber es ist irgendwie doch noch zu vieles unklar.
Ich glaube, ich werde lwip als Vorlage nehmen und nach meinem Gusto 
umschreiben.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tobias:

Der lwip Stack gefällt dir nicht, aber der funktioniert doch schon mal 
recht gut.

Ist es denn nicht um ein vielfaches einfacher den lwip hier und da ein 
wenig um zu schreiben und zu optimieren?
Und dann zu dokumentieren?

Damit hätte man sechs Fliegen mit einer Klappe:
- Das ganze wird übersichtlicher
- lwip wird besser
- und dass lwip besser wird, darüber würden sich garantiert viele hier 
freuen
- damit würdes du viel bessere Unterstützung in diesem Forum/Usern 
bekommen
- und es würden sich mehr leute finden die das dann auch testen würden
- du musst nicht alles optimieren, sondern nur der Teil der dir nicht 
gefällt, somit kannst du irgendwann wieder aufhören und das 
(funktionierende) Ergebnis der open-source Gemeinde überlassen.

Das würde wirklich vielen helfen.

Denn bis dein Code, von 0 beginnend gut und fehlerfei ist gehen sicher 
1-2 Jahre vorbei. Da den dann niemand kennt und warscheinlich schonmal 
lwip verwendet wurde, wird den auch niemand haben wollen.

Überlege dir das wirklich nochmal mit dem selbst schreiben von 0 (null) 
beginnend.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus,
ja ich werde wohl nicht umhin kommen, das so zu machen.
Allerdings wird das auch nicht einfach. Ich möchte lwip so umschreiben, 
dass er sich nahtlos in mein uC/OS System integriert, das heisst dann 
natürlich auch, dass die ganzen APIs umgeschrieben werden müssen. Zudem 
möchte ich diese pbufs nicht haben. Denn dort müssen die Pakete, die 
versandt werden wollen, erst in einen solchen pbuf rein kopiert werden, 
bzw. empfangene Pakete müssen aus den pbufs raus kopiert werden. Das ist 
mühsam, unschön und verschwendet CPU Zeit, und es ist unnötig, wenn man 
einen MAC hat, der DMA kann.
Von 0 an selber schreiben hätte natürlich auch was für sich, 
schliesslich kann nicht jeder behauptet haben, selber einen TCP-Stack 
entworfen zu haben ;-)

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem pbuf muss man nichts kopieren. pbuf ist doch ein Zeiger auf 
einen Buffer, einfach diesem Zeiger eine andere Adresse zuweisen, 
fertig.

Oder etwa nicht?

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein. lwip hat einen eigenen memory manager, der verschiedene Pools zur 
Verfügung stellt, und ein pbuf ist eine verkettete Liste von solchen 
Pools.
Eben genau dies gefällt mir z.B. nicht am lwip. Ich finde dies unnötig 
kompliziert. Man hätte es wenigstens so machen können, dass pro Paket 
ein einziger Buffer alloziiert wird, der so gross ist, dass das Paket 
grade rein passt. Dann hätte man sich auch den memory manager sparen 
können.....

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> Nein. lwip hat einen eigenen memory manager, der verschiedene Pools zur
> Verfügung stellt, und ein pbuf ist eine verkettete Liste von solchen
> Pools.
> Eben genau dies gefällt mir z.B. nicht am lwip. Ich finde dies unnötig
> kompliziert. Man hätte es wenigstens so machen können, dass pro Paket
> ein einziger Buffer alloziiert wird, der so gross ist, dass das Paket
> grade rein passt. Dann hätte man sich auch den memory manager sparen
> können.....

Der Memory Manager hat seinen Sinn. Ich tippe mal darauf, dass Du noch 
nie auf einem Amiga programmiert hast, weil Du einfach zu jung bist. Das 
AmigaOS war ein sehr schlankes Betriebssystem, das für einen 68k ohne 
MMU entworfen wurde. Da konnte es Dir nach einiger Zeit passieren, dass 
Du zB einen 2MB Speicherblock brauchtest, ihn aber nicht bekommen hast, 
obwohl noch insgesamt 4.5MB frei waren, davon aber 500 MB im Chip-RAM 
und zwei 1.5MB und ein 1MB Block im Fastram. Schade auch. Da war dann 
ein Reboot fällig, oder zumindest alle Programme schließen und neu 
starten. So etwas nennt man Speicherfragmentierung und kann auf allen 
Systemen ohne MMU passieren. Bei Embedded Systemen fordert man den 
Speicher daher genau einmal am Anfang an und arbeitet damit fortan, eben 
um genau die beschriebene Situation zu vermeiden.

Nach Deinem letzten Posting möchte ich sagen "Lass es". Geh davon aus, 
dass sich der Adam Dunkel schon etwas dabei gedacht hat und versuch den 
Grund dafür rauszufinden.

fchk

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank,
ich weiss schon, was es heisst, wenn das memory fragmentiert ist. 
AmigaOS kenne ich tatsächlich nur vom hörensagen, den 68k dafür aber 
umso besser.
Ich würde aber mal behaupten, dass das memory kaum fragmentiert, wenn 
man genug davon hat. Oder? Und das ist bei mir der Fall, ich habe so 
viel Memory, dass ich wohl gar nicht alles brauchen kann. Nachdem ich 
jetzt einen anderen Chip aufgelötet habe, verfüge ich über 64M x 32 
Memory, also 256 MBytes. Das sollte auch für den dicksten Stack noch 
reichen.
Wenn der Dunkels schon diesen Memory Manager entworfen hat: wieso hat er 
den nicht gleich so designt, dass ein ganzes paket in einen einzelnen 
pbuf passt? Ich habe nämlich vor einiger Zeit mit lwip rumgedoktert 
(habe ihn allerdings nie recht zum laufen gekriegt). Dort musste dann 
auf umständliche Weise ein eingetroffenes Paket in einen solchen pbuf 
rein kopiert werden. Und wenn ein Paket versendet werden sollte, dann 
musste man erst einen pbuf alloziieren, und dann die Paketdaten in 
diesen pbuf rein kopieren. Warum spart man sich diese Kopiererei nicht 
einfach? Ich versteh's wirklich nicht. Aber ich gehe mal davon aus, dass 
es auf einem PC wohl kaum auch so gemacht wird, denn dann würde man ja 
die meiste CPU-Zeit nur für das sinnlose rumkopieren von Daten benutzen.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias schrieb:
> Frank,
> ich weiss schon, was es heisst, wenn das memory fragmentiert ist.
> AmigaOS kenne ich tatsächlich nur vom hörensagen, den 68k dafür aber
> umso besser.
> Ich würde aber mal behaupten, dass das memory kaum fragmentiert, wenn
> man genug davon hat. Oder? Und das ist bei mir der Fall, ich habe so
> viel Memory, dass ich wohl gar nicht alles brauchen kann. Nachdem ich
> jetzt einen anderen Chip aufgelötet habe, verfüge ich über 64M x 32
> Memory, also 256 MBytes. Das sollte auch für den dicksten Stack noch
> reichen.

"kaum fragmentiert" ist genauso wie "kaum abstürzt" bei Windows 98, wenn 
der Systick Counter nach 49,7 Tagen überläuft - Pfusch. Ein gutes System 
sollte Jahre ohne Störungen durchlaufen. Bei Netware und 
Solaris-Maschinen habe ich schon vierstellige Uptimes gesehen.

> Wenn der Dunkels schon diesen Memory Manager entworfen hat: wieso hat er
> den nicht gleich so designt, dass ein ganzes paket in einen einzelnen
> pbuf passt?

Vielleicht fragst Du ihn einfach oder liest seine Papers? Ich denke, es 
war eine Designentscheidung, um den Speicherbedarf zu reduzieren.

Mit 256 MB könntest Du auch zum BSD Stack greifen. Das ist sozusagen die 
Referenz, von der alle anderen abgepinnt haben.

fchk

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ihm bereits eine Mail geschickt und warte auf eine Antwort.
Den BSD-Stack werde ich mir anschauen, danke für den Tipp!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.