ESP8266 - Artikel zum Wiki

Persönliche Seite #3938874
Lesenswert?

Hallo zusammen,

* ich baue gerade eine ESP8266-Bibliothek (ARM mit
  DMA-Ringbuffer auf STM32),
* mir war dabei im Artkel ESP8266 ein Fehler aufgefallen und
* ich habe eine kleine Frage.

Dieser Thread soll den Anspruch haben, Fragen, die Im Wiki nicht 
beantwortet werden, stellen zu können. Wenn Antworten da sind, würde ich 
die im Wiki ergänzen.

Zu meiner Frage: Ich eröffne mit AT+CIPSERVER=1,80 einen Server für 
HTTP-Requests. Wenn ein Browser zugreift, kommt "Link". Wenn der nächste 
Zugreift, kommt nochmal "Link".

An +IPD,0,… oder +IPD,1,… usw. kann ich erkennen, von welchem Request 
die empfangenen Daten gerade kommen.

Nun muss ich die Daten ja sammeln, den HTTP-Herader auswerten usw.. 
Dafür benutze ich einen Zustandsautomaten.

Meine Frage: Wenn die Verbindung abgebrochen wird, kommt ja ein 
"Unlink". Aber wie finde ich heraus, welcher Request gerade abgebrochen 
wurde? Ich muss ja die Statemachine für den einen Request weiter laufen 
lassen und die andere für das nächste "Link" zurücksetzen.
Gast #3939570
Lesenswert?

Bei HTTP spielen Verbindungsaufbau und Ende keine Rolle. Wenn dein 
Server von diesen Ereignissen abhängt, hast du ihn fehlerhaft 
implementiert.

Entscheident sind Requests und Response. Ein Request endet mit einer 
Leerzeile. Die Response endet nach der im Header angekündigten Anzahl 
von Bytes.

Wenn dein Server keine Ahnung hat, wie viele Bytes er senden wird, kann 
er alternativ auch auf die ANgabe im Header verzichten und stattdessen 
das Ende durch Trennen der Verbindung ankündigen. Aber das sollte man 
vermieden, wenn es irgendwie geht. Denn so können die Browser keinen 
anständigen Ladebalken anzeigen und der Browser muss nach jeder 
einzelnen Dateil immer wieder eine neue Verbindung aufmachen, was Zeit 
kostet.

Zusätzlichen arbeiten Server und Browser mit einem Timeout 
(typischerweise 60 Sekunden) damit sie sich nicht aufhängen.
Persönliche Seite #3939930
Lesenswert?

Stefan Us schrieb:
> Bei HTTP spielen Verbindungsaufbau und Ende keine Rolle. Wenn dein
> Server von diesen Ereignissen abhängt, hast du ihn fehlerhaft
> implementiert.

Ob das Wort "Fehlerhaft" hier angemessen ist? Zumindest ist so ein 
Server dann nicht robust programmiert.

Bei drei oder vier offenen Verbindungen kann ich mir schon vorstellen, 
dass bei einem Abbruch und Neuaufbau einer Verbindung mal ein 
Requst-Header versehentlich für Upload-Daten des Vorgängers gehalten 
wird.

Aber mit dem ESP8266 wird man solche Anwendungen kaum haben und ich will 
hier jetzt keine Grundsatzdiskussion über irgendwelche Sonderfälle, die 
theoretisch möglich wären.

Jedenfalls habe ich wohl nichts übersehen: Es hätte ja sein können, dass 
es eine Möglichkeit gibt, bei einem "Unlink" den Kanal herauszufinden.

Stefan Us schrieb:
> Wenn dein Server keine Ahnung hat, wie viele Bytes er senden wird…

Bei "+IPD,0,… oder +IPD,1,… usw."^^ geht es um empfangene Daten 
(Requests), nicht um gesendete.

HTTP ist ja nicht das einzig denkbare, was man mit Telnet machen kann. 
Dann muss man halt alle Protokolle so implementieren, dass man mit einem 
"Unlink" ohne Kanalnummer auskommt.
Persönliche Seite #3940454
Lesenswert?

Stefan Us schrieb:
> Hast du mal AT+CIPSTATUS? probiert. Vielleicht hilft dessen Ausgabe?

Cool, danke. :-)

Keine Verbindung:
1
AT+CIPSTATUS
2
STATUS:4
3

4
OK

Zwei Verbindungen:
1
AT+CIPSTATUS
2
STATUS:3
3
+CIPSTATUS:0,"TCP","192.168.178.21",56694,1
4
+CIPSTATUS:1,"TCP","192.168.178.21",56703,1
5

6
OK

Also nach jedem "Link" oder "Unlink" einfach mal nachschauen! Danke!

PS: Wobei ich mich frage, ob man im Wiki-Artikel alle Kommandos usw. 
genauer beschreiben sollte. Hier z.B. gibt es eine FW mit deutlich 
umfangreicheren Kommandos:

https://github.com/igrr/atproto

Da macht eine Gesamtübersicht eigentlich nur Sinn, wenn auch immer dabei 
steht, mit welcher Firmware welches Kommando unterstützt wird. Bei mir 
z.B.:

> AT+GMR => 00160901
> AT+GMM => ERROR
> AT+GSN => ERROR
> ATV => ERROR
> ATE0 => no this fun
> ATQ1 => ERROR
> AT+GMEM => ERROR
> AT+IDBG? => ERROR
> AT+IPR? => ERROR

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren