ESP8266 als TCP Server verschluckt Client Pakets

[Georg W. (gewe)]

Hallo zusammen,

ich habe folgenden Aufbau:

PC mit C# Anwendung welche im 1 Sekundentakt als TCP Client eine 
Verbindung zum ESP aufbaut, 4 Bytes an einen ESP8266 sendet und die 
Verbindung abbaut.

Der ESP8266 wird mit der Arduino IDE programmiert. Boadrdefinitionen und 
Bibliotheken sind aktuell.

Ich habe das Beispiel von Stefan Frings versucht auf eine feste 
Kommandolänge von 4 Bytes umzustellen.

http://stefanfrings.de/esp8266/#atserver

Der komplette Sketch ist im Anhang.

Die geänderte Funktion sieht so aus:

bool getCommand(Stream& source, char* buffer, int bufSize, char maxLength)
{
    int data=source.read();
    if (data>=0)
    {
        int len=static_cast<int>(0);
        do
        {
            #ifdef DEBUG
            if (len==0)
            {
              Serial.println(F(""));
              Serial.print(F("Packet started: "));
              PaketCount++;
              Serial.println(PacketCount);
            }
            #endif
          
            if (len<bufSize-1)
            {
                buffer[len++]=static_cast<char>(data);
            }
            if (len==maxLength)
            {
                buffer[len]='\0';
                len=0;
                #ifdef DEBUG
                Serial.println(F("Packet done"));
                #endif
                return true;
            }
            data=source.read();
        }
        while (data>=0);
        buffer[len]='\0';  
    }
    return false;
}

Was jetzt passiert ist folgendes:

Obwohl ich im Wireshark sehe, dass die Pakete der C# Anwendung rausgehen 
und vom ESP8266 auch quittiert werden, springt die Empfangsroutine 
sporadisch nicht an. Das Problem tritt ca. einmal pro 10 Übertragungen 
auf. Jedoch konnte ich keine Muster erkennen, wann es auftritt.

Das Verhalten tritt mit und ohne aktivierten Debugausgaben auf.

Der gleiche Aufbau mit NodeMcu Firmware 3.0.0.0 und einem LUA Programm 
läuft über eine Stunde stabil.

Hat jemand einen Tipp für mich, wo ich schauen kann. bzw. was die 
Ursache sein könnte?

cu
Georg

[Ralf G. (ralg)]

Habe gerade deinen etwas älteren Beitrag gelesen. Schon eine Lösung 
gefunden? Falls nicht: Ich habe festgestellt, dass mit 
'server.available()' zwar ein 'WiFiclient'-Objekt erzeugt wird, aber ein 
nachfolgendes 'client.available()' keine Daten 'meldet'. Ich warte 
einfach etwas auf die Daten:

#define BUFFER_SIZE 512
static char client_buffer[BUFFER_SIZE];

uint_fast8_t handle_client()
{
  memset( client_buffer, 0, BUFFER_SIZE );
  WiFiClient client = server.available();
  if ( !client )
    return 1;
  
  uint_fast16_t count = 0;
  for (uint_fast8_t i = 0; i < 20; i++)
  {
    count = client.available();
    if (count)
      break;
    delay(5);
  }
  if ( !count )
    return 2;
    
  for (uint_fast16_t i = 0; i < count; i++)
  {
    if ( client.connected() )
    { 
      client_buffer[i] = client.read(); 
    }
    else
    {
      client.stop();
      return 3;
    }
  }

// 
// weiter im Programm
//

  return 0;
}

[Georg W. (gewe)]

Danke, für die Info.

Werde ich am Wochenende mal testen.

[Stefan F. (Gast)]

Ralf G. schrieb:
> Ich habe festgestellt, dass mit
> 'server.available()' zwar ein 'WiFiclient'-Objekt erzeugt wird, aber ein
> nachfolgendes 'client.available()' keine Daten 'meldet'.

Das ist logisch.

Der server ist avalilable() sobald eine Verbindung aufgebaut wurde.
Der client ist available() sobald er Daten empfangen hat.

Bei UDP wäre das was anderes, denn da gibt es keinen Verbindungsaufbau.

Wenn du Zeichenketten mit variabler Länge empfangen willst, dann guck 
mal von diesem Beispiel ab: 
http://stefanfrings.de/esp8266/index.html#tcpsketch

Die Funktion append_until() wird hier wiederholt aufgerufen, um die 
empfangenen Zeichen einzusammeln bis ein bestimmtes Trennzeichen (z.B. 
Zeilenumbruch) empfangen wird. Danach wird die bis dahin empfangene 
Zeichenkette verarbeitet.

Ich bevorzuge in den meisten Anwendungen Zeichenketten gegenüber 
Rohdaten, weil man das leichter manuell simulieren kann. Den eventuell 
nötigen technischen Mehraufwand zum Parsen von Zahlen gönne ich mir. 
Soll der Computer doch für mich arbeiten, nicht umgekehrt.

Ich würde auch immer daran denken, was passiert (bzw. was passieren 
soll), wenn mehrere Verbindungen gleichzeitig bestehen. Sollen sie sich 
gegenseitig blockieren? Soll nur eine zugelassen werden und die anderen 
abgelehnt werden? Einfach nur eine Verbindung verarbeiten und die 
anderen ignorieren ist keine gute Idee, denn das steht einer sauberen 
Fehlerbehandlung im Weg. Dabei immer auch an das andere Ende der Leitung 
denken, wie soll das Fehler erkennen und reagieren?

TCP arbeitet einigermaßen Zuverlässig. Wenn du Daten empfängst, dann 
sind sie wahrscheinlich unverfälscht und in der richtigen Reihenfolge. 
Du musst aber jederzeit damit Rechnen, das eine Verbindung nicht 
aufgebaut werden kann, oder unerwartet abbricht, oder für bis zu einer 
Minute stockt, oder eine Bestätigung des Empfängers für erfolgreich 
übertragene Daten beim Sender nicht ankommt.

[Ralf G. (ralg)]

Stefan ⛄ F. schrieb:
> Das ist logisch.

Und warum funktioniert's dann nicht? (Ist 'ne rhetorische Frage.) Der TO 
hat dein Beispiel in Verwendung.

[Georg W. (gewe)]

Ralf G. schrieb:

> Und warum funktioniert's dann nicht? (Ist 'ne rhetorische Frage.) Der TO
> hat dein Beispiel in Verwendung.

Hallo Ralf,

ich denke ich kann die Frage jetzt mal vorübergehend beantworten.

Ich habe eine Nodemcu Applikation, die sauber funktioniert hat.

Diese habe ich zum erneuten Test auf ein ESP01-S Modul gespielt und ich 
bekam Verbindungsprobleme.

Die gleiche Applikation auf ein anderes ESP01-S Modul gespielt und es 
läuft wieder.

Danach habe ich das angepasste Beispiel von Stefan auf das 
"funktionsfähige" Modul gespielt und siehe da, es läuft vorläufig auch.

Die Module stammen aus zwei unterschiedlichen Bestellungen und so wie es 
aussieht, machen eventuell die Module aus einer Bestellung Probleme.

Ich werde mich nochmal melden, wenn ich mehr getestet habe.