4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    version = "0.0.2.183 - Rev: 1026" (in ckernel.c: versehentlich 1025)

    tcp: in/out Buffer angefangen

    arp: nicht table, sondern cache (führt zu cache->table, besser als table->table)

    user-prg:
    irc.elf etwas weiter entwickelt.

    0
  • E
    Mod

    version = "0.0.2.184 - Rev: 1027"

    tcpIn_t, tcpOut_t, ... hinzu gefügt.

    Problem: tcp.c, Zeile 432 ff.: Fill in-buffer list arbeitet zu langsam.
    Aktiviert man memcpy(In->data, ...), dann bleibt der starwars-Empfang in Qemu hängen (Test auf einen hohen Dateninput). Kann man event.buffer und In->data (dauerhaft auf dem Heap) kombinieren und das doppelte memcpy sparen?

    Vielleicht benötigen wir auch ein schnelleres memcpy in Assembler.

    beep weg (sehr lästig beim Testen)

    Code läst sich bis -O2 compilieren, dann gehen auch beide memcpy, allerdings nicht mit -O3, dort kommt ein Fehler bei der checksum-Routine.

    0
  • E
    Mod

    Lösungsvorschlag:

    uint16_t udptcpCalculateChecksum(void* p, uint16_t length, IP_t srcIP, IP_t destIP, uint16_t protocol) 
{ 
    updtcpPseudoHeader_t pseudo = { srcIP, destIP, 0, protocol, htons(length) }; 
    uint32_t pseudoHeaderChecksum = 0; 

    for(uint32_t i = 0; i < sizeof(updtcpPseudoHeader_t); i+=2) 
    { 
        pseudoHeaderChecksum += htons(((uint16_t*)&pseudo)[i]); 
    } 

    return internetChecksum(p, length, pseudoHeaderChecksum); 
}
    0
  • M

    Den O3-Fehler kenne ich. Ist afaik ein Bug in GCC 4.4.0, der in gcc 4.4.4? gefixt wurde. Da es aber keinen Grund gibt, mit -O3 zu kompilieren, denke ich, dass ein Workaround nicht nötig ist.

    0
  • M

    Version 0.0.2.185:

    - IRC-Programm verbessert: Joinen mit Strg+J, Senden an #PrettyOS mit Strg+P
    - Padding wird nun in ipv4.c entfernt und nicht mehr (fehlerhaft) in tcp.c.
    - Paket- und Headerlängen in tcp.c und ipv4.c korrekt verwendet.

    0
  • E
    Mod

    version = "0.0.2.186 - Rev: 1029"

    @MrX: hab deinen Vorschlag umgesetzt, aber es besteht ein Zugriffsproblem von user nach kernel heap.

    Experimenteller Zwischenstatus: Übergabe eines Events in tcp.c mit buffer als Zeiger. Ist Array notwendig? Wenn ja, welche Größe?
    Problem: Daten stecken im Kernel Heap. Wie greift man darauf von user-land aus zu? (Erfolgloser Versuch in browser.c, irc und starwars noch unverändert, wieso gibt das keinen #PF?) 🙄

    MrX: Idee, wie man das auflösen kann?

    memcpy durch etwas schnellere Assembler-Version ersetzt.

    0
  • E
    Mod

    Anmerkung aus #lost: wir sollten mehr Unterordner einziehen unter \kernel.

    0
  • E
    Mod

    version = "0.0.2.187 - Rev: 1030"

    - TCP-Datentransfer nun korrekt von kernel nach user
    - TCP-Datentransfer beschleunigt

    0
  • E
    Mod

    version = "0.0.2.188 - Rev: 1031"

    - kleine Änderungen in tcp.c und types.h (connectionID)
    - bei receive FIN,ACK (geht bei browser.c) werden testweise die Pakete in der IN-Queue angezeigt: Seq, len, data (funktioniert!)

    0
  • E
    Mod

    version = "0.0.2.188 - Rev: 1032"

    - irc angepasst, damit ein zufälliger Name (Pretty+Zufallszahl) gebildet wird.

    - Pretty14309 joined
    <Pretty14309>hi
    <ehenkes>test
    - Pretty14309 quit (Client exited)

    - Pretty17705 joined
    <Pretty17705>schon wieder da ^^
    - Pretty17705 quit (Connection reset by peer)

    - Pretty19370 joined
    ...
    - Pretty19370 quit (Connection reset by peer)

    0
  • E
    Mod

    version = "0.0.2.188 - Rev: 1033"

    Hinweis von Kollegen aus #lost auf die Pflicht, sich mit QUIT zu entfernen.
    “A client session is ended with a quit message.”

    Dem kommen wir gerne nach. Kostet aber schon wieder zwei Zeilen.;)

    case KEY_ESC:
{
    char* msgQuit = "QUIT\r\n";
    tcp_send(connection, msgQuit, strlen(msgQuit));
    tcp_close(connection);
    return(0);
}

    - Pretty31812 joined
    <Pretty31812>test auf quit
    - Pretty31812 quit (Life is too short...)

    - Pretty28547 joined
    <Pretty28547>nochmal jetzt mit ESC weg
    - Pretty28547 quit (Life is too short...)

    0
  • E
    Mod

    version = "0.0.2.189 - Rev: 1034"

    - memcpy, memset nun schneller (MrX)
    - irc.c (Nummernausgabe weg)

    0
  • M

    Version 0.0.2.190:

    - console.c: Bugfix: console_clear ändert Textfarbe nicht mehr.
    - memshow: Bugfix bei count%16!=0: Darstellung korrigiert.
    - memsetl durch memset ersetzt (Performance-Hack nicht mehr nötig)
    - optimiertes memset/memcpy auch im Userspace, memsetw ebenfalls optimiert
    - Shell:
    -- Bugfix: Eingabezeile nun korrekt gelöscht.
    -- Bugfix: Cursorposition wird zurückgesetzt, wenn Eintrag mit Pfeiltaste nach unten gelöscht wird.
    - Kleinigkeiten

    0
  • E
    Mod

    version = "0.0.2.191 - Rev: 1036"

    Steuerungsmechanismus window mittels Feedback aus event_issue testweise installiert, um Erfahrung zu bekommen.

    0
  • E
    Mod

    version = "0.0.2.192 - Rev: 1037"

    Gesamtgröße der TCP-Daten in der Event-Queue bestimmt

    0
  • E
    Mod

    version = "0.0.2.193 - Rev: 1038"

    Versuchsweise Steuerung des sliding window mit der Gesamtmenge an TCP-Data (bytes) in der Event Queue des task.

    0
  • E
    Mod

    version = "0.0.2.194 - Rev: 1039"

    tcp ausgaben stark vereinfacht

    0
  • E
    Mod

    version = "0.0.2.195 - Rev: 1040"

    Fehler in TCP korrigiert (z.B. window Steuerung)

    0
  • E
    Mod

    version = "0.0.2.196 - Rev: 1041"

    Eigenes Ping, also ICMP_echoRequest, eingebaut, und Empfang auf den ICMP_echoReply erweitert. leider funktioniert das auf der VM Qemu bisher noch nicht. Daher sollte man zunächst auf Hardware testen.

    Hier das Ergebnis auf strg+p:

    case 'p':
{
  IP_t destIP; // www.henkessoft.de
  destIP.IP[0] =    82; destIP.IP[1] =   100; 
  destIP.IP[2] =   220; destIP.IP[3] =    68;

  network_adapter_t* adapter = network_getFirstAdapter();
  if (adapter)
  {
    ICMP_echoRequest(adapter, destIP);
  }
  break;
}

    Folgendes tauscht dann als Analyse des Echos in PrettyOS wieder auf:

    ICMP_echoReply:  ID: AFFE seq: 1 
PrettyOS ist das Betriebssystem der Projektgru
ppe "OS-Development" im deutschsprachigen C++-Forum ...

    (Anmerkung: string wird noch nicht korrekt ausgelesen. Zeichen danach?)

    aus wiki: Das „Daten“-Feld kann jedoch auch dazu missbraucht werden, um Nutzdaten zu übertragen (ICMP-Tunneling). 😉 Werbung für PrettyOS und c++.de 😉
    hrping hat Cäsars de bello Gallico als Datensatz. 😃

    Macht man dies mit dem qemu hack, so taucht beim Versuch des Erreichens des Host-Subnets eine ICMP Botschaft in wireshark auf, die wir bisher noch nicht analysieren: "destination unreachable".

    264 27.444422 10.0.2.15 192.168.1.1 ICMP 2187 Echo (ping) request id=0xaffe, seq=1/256, ttl=128
    265 27.444593 10.0.2.2 10.0.2.16 ICMP 120 Destination unreachable (Port unreachable)

    ICMP bietet hiermit einen vielleicht guten Weg, um das qemu subnet 10.0.2.x und den Zusammenhang zum Host subnet (hier 192.168.1.x) zu analysieren und qemu so einzurichten, dass wir letztendlich auch unter Windows auf den störenden qemu hack verzichten können.

    siehe: http://de.wikipedia.org/wiki/Internet_Control_Message_Protocol

    0
  • M

    Version 0.0.2.197:

    - BL1 und BL2: Code aufgeräumt/optimiert, Hotfixes gesichtet und ggf. entfernt.
    - memcpy, memset und memsetw weiter verbessert; Zwei Bugs entfernt.
    - Weitere Funktionen in Standardlib implementiert

    0
Anmelden zum Antworten