Komische Daten vom Server

Soundthesizer, Zusitool und andere Zusatzsoftware

Moderatoren: Andreas Damm, Jens Haupert

Nachricht
Autor
protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Client Verbindung zum TCP Server geht nicht

#1 Beitrag von protonmw (Marc) »

Hallo liebe Zusianer!

Hab mal ein kleines Programm in C geschrieben, mit dem ich mich mit dem TCP Server verbinden möchte. Leider scheitert es schon beim HALLO... Irgendwie kommt das HALLO ACK nicht. Habe es so wie in der Dokumentation gemacht. Weiß einer woran das liegen könnte?

EDIT: Code angefügt
EDIT2: Die Socket Verbindung geht. Auch das Datenpaket geht raus. Es kommt aber nix zurück. (Mit Netzwerk Sniffer überprüft!)

Code: Alles auswählen

#include <windows.h>
#include <stdio.h>
#include <conio.h>

#pragma comment(lib,"ws2_32.lib")

u_short port=1435;

int startWinsock(void){
	WSADATA wsa;
	return WSAStartup(MAKEWORD(2,0),&wsa);
}

int main(){
	long rc;
	SOCKET s;
	SOCKADDR_IN addr;
	char buf[512];
	char inputbuf[1024];

	rc=startWinsock();
	if(rc!=0){
		printf("Fehler: startWinsock, fehler code: %d\n",rc);
		return 1;
	}
	else{
		printf("Winsock gestartet!\n");
	}

	s=socket(AF_INET,SOCK_STREAM,0);
	if(s==INVALID_SOCKET){
		printf("Fehler: Der Socket konnte nicht erstellt werden, fehler code: %d\n",WSAGetLastError());
		return 1;
	}
	else{
		printf("Socket erstellt!\n");
	}

	memset(&addr,0,sizeof(SOCKADDR_IN));	//zuerst alles auf Null setzen
	addr.sin_family=AF_INET;
	addr.sin_port=htons(port);
	addr.sin_addr.s_addr=inet_addr("192.168.1.5");

	rc=connect(s,(SOCKADDR*)&addr,sizeof(SOCKADDR));
	if(rc==SOCKET_ERROR){
		printf("Fehler: connect gescheitert, fehler code: %d\n",WSAGetLastError());
		return 1;
	}
	else{
		printf("Verbunden mit 192.168.1.5 \n");
	}

	buf[0]=0x00;	//Paketlänge 4 Byte
	buf[1]=0x00;
	buf[2]=0x00;
	buf[3]=0x0D;	
	buf[4]=0x00;	// Hello Befehl 2 Byte
	buf[5]=0x01;
	buf[6]=0x02;	// Version 1 Byte
	buf[7]=0x02;	// Client Type 1 Byte
	buf[8]=0x08;	// Länge des Identifiers
	buf[9]=0x46;
	buf[10]=0x61;
	buf[11]=0x68;
	buf[12]=0x72;
	buf[13]=0x70;
	buf[14]=0x75;
	buf[15]=0x6C;
	buf[16]=0x74;



	//strcpy((buf+9),"Fahrpult\n");

	printf(buf);
	send(s,buf,17,0);
	recv(s,inputbuf,1024,0);

 	while(!_kbhit());
	return 0;
}
Zuletzt geändert von protonmw (Marc) am 11.09.2009 13:34:54, insgesamt 2-mal geändert.
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

Re: Client Verbindung zum TCP Server geht nicht

#2 Beitrag von Andreas Karg »

Wenn ich das richtig sehe, ist deine HELLO-Nachricht nur 13 Bytes lang -- die Längenangabe sagt aber 14. Ich vermute mal, der Server wartet noch auf das fehlende Byte.

Ich hab mich mit dem Zusi-TCP-Protokoll die letzten Wochen auch rumschlagen dürfen, weil ich es in C# implementiert habe. Aber inzwischen läuft's. *stolz*
Falls hier zufällig ein .NET-Nutzer 'rumhüpft, der meine Schnittstelle gern mal testen würde, darf er sich melden. Ich bilde mir ein, das Ding schön sauber geschrieben zu haben. Einzig eine ausführliche Dokumentation würde noch fehlen...

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Client Verbindung zum TCP Server geht nicht

#3 Beitrag von protonmw (Marc) »

Was? Wie kommst du auf 14?

Habe auch schon die Länge im Verdacht. Was gehört denn alles zum Paket?

(PS: bei mir ist die 13 die hex 0D ...oder??)
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

Benutzeravatar
Jens Haupert
Beiträge: 4920
Registriert: 23.03.2004 14:44:34
Aktuelle Projekte: http://www.zusidisplay.de
Wohnort: Berlin
Kontaktdaten:

Re: Client Verbindung zum TCP Server geht nicht

#4 Beitrag von Jens Haupert »

Andreas Karg hat geschrieben:Ich hab mich mit dem Zusi-TCP-Protokoll die letzten Wochen auch rumschlagen dürfen, weil ich es in C# implementiert habe. Aber inzwischen läuft's. *stolz*
Falls hier zufällig ein .NET-Nutzer 'rumhüpft, der meine Schnittstelle gern mal testen würde, darf er sich melden. Ich bilde mir ein, das Ding schön sauber geschrieben zu haben.
Ui,
dann wird's auf jedenfall besser sein als meine Implementierung. :O
Andreas Karg hat geschrieben:Einzig eine ausführliche Dokumentation würde noch fehlen...
Willkommen im Club. ;( :D

MfG Jens

Bernhard
Beiträge: 22
Registriert: 11.09.2009 15:44:19

Re: Client Verbindung zum TCP Server geht nicht

#5 Beitrag von Bernhard »

protonmw hat geschrieben:

Code: Alles auswählen

	buf[0]=0x00;	//Paketlänge 4 Byte
	buf[1]=0x00;
	buf[2]=0x00;
	buf[3]=0x0D;	
Die Paketlänge muß in Little-Endian-Bytereihenfolge angegeben werden:

Code: Alles auswählen

	buf[0]=0x0D;	//Paketlänge 4 Byte
	buf[1]=0x00;
	buf[2]=0x00;
	buf[3]=0x00;	

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Client Verbindung zum TCP Server geht nicht

#6 Beitrag von protonmw (Marc) »

Danke Bernhard. Das war der richtige Tipp!
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

Re: Client Verbindung zum TCP Server geht nicht

#7 Beitrag von Andreas Karg »

Hm. :-D Anscheinend hab ich als Kind zu wenig Sesamstraße geschaut. Das mit dem Zählen sollte ich jedenfalls noch üben. :-D
Zum Klugscheißen reicht's aber. ^_^ Ich hatte 0x0D irgendwie als 14 im Kopf. Fragts mich net, warum.

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Komische Daten vom Server

#8 Beitrag von protonmw (Marc) »

Sorry für den blöden Threadtitel... mir viel nix besseres ein.

Meine Programmierversuche machen mittlerweile Fortschritte. Aber jetzt steh ich wieder vor einem Problem. ;(

Ich hab beim Server als Daten die Fahrstufe angemeldet. Das hat auch geklappt. Wenn ich jetzt mit dem Programm "ZuSim" das ganze teste, dann funktionert auch alles soweit solange der "Zug" steht und ich negative Fahrstufen hin und her schalte...

Der Sniffer zeigt hier auch ein korrektes Datenpaket an:
07 00 00 00 00 0a 10 00 00 80 3f z.B.

Sobald sich der Zug aber in Bewegung setzt werde ich zugmüllt mit nem Haufen von Müllpaketen:
02 00 00 00 00 0a 02 00 00 00 00 0a <- und das ist 1!!!! Datenpaket (aber mit scheinbar doppeltem Inhalt)


Als angefordert wird in ZuSim wie auch in Zusi nur "Fahrstufe" angezeigt.
Zusi zeigt das gleiche Verhalten.

Mache ich etwas verkehrt? Hoffe ihr könnt das so nachvollziehen...
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33445
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Komische Daten vom Server

#9 Beitrag von Carsten Hölscher »

Ist die byte-Reihenfolge korrekt herum interpretiert?

Carsten

ImmoBirnbaum
Beiträge: 1040
Registriert: 18.01.2004 12:51:32
Aktuelle Projekte: Objektbau in LOD0, Fahrpult, new adventures in VHDL
Wohnort: EPD

Re: Komische Daten vom Server

#10 Beitrag von ImmoBirnbaum »

Das Paket kann wie oben dargestellt eigentlich nicht in der falschen Richtung gelesen sein.
Die Paketlänge 0A = 10 Bytes würde schon nicht stimmen, und wie oben dargestellt ergibt das Paket schon sinn: die ersten 4 Bytes zeigen in Little Endian-Reihenfolge 2 Bytes Daten an, die Datenbytes sind 00 0A, was dem Befehl DATA entspricht. Es folgen nur keine Datensätze.

Ich meine mich zu erinnern, dass ich solche obskuren Pakete auch mal beobachtet habe, als ich die Firmware für meine ATMEL-Controller geschrieben habe. Fordere einfach mal zusätzlich noch die aktuelle Geschwindigkeit mit beim Server an, auch wenn Du sie nicht brauchst. Die Geschwindigkeit wird mit so ziemlich jedem Paket aktualisiert, prüfe dann mal, ob die Pakete dann sinnvoller aussehen. Falls Du als Sniffer Ethereal/Wireshark benutzen solltest, kannst Du mal eine Session inkl. Anmeldung beim Server speichern und zur Auswertung irgendwo hochladen? Die meisten seltsamen Effekte habe ich beobachtet, wenn irgendwo eine Paketlänge beim Anmeldevorgang nicht stimmte - das bedeutet nicht zwangsläufig den Abbruch der Verbindung, sondern es kommt halt irgendwelcher Murks raus...
SAAB - more than a car

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Komische Daten vom Server

#11 Beitrag von Christopher Spies »

Hallo "protonmw",
ImmoBirnbaum hat geschrieben:wie oben dargestellt ergibt das Paket schon sinn: die ersten 4 Bytes zeigen in Little Endian-Reihenfolge 2 Bytes Daten an, die Datenbytes sind 00 0A, was dem Befehl DATA entspricht. Es folgen nur keine Datensätze.
so sehe ich das auch.
Diese leeren Pakete sollte man doch einfach ignorieren können, oder?
protonmw hat geschrieben:das ist 1!!!! Datenpaket (aber mit scheinbar doppeltem Inhalt)
Zeigt der Sniffer das auch als ein Paket an?

Es könnte sein, dass Deine Empfangsroutine nicht ganz korrekt ist und deshalb aufeinanderfolgende Pakete als ein Paket liest. Oder es könnte sein, dass mehrere von Zusi gesendete Pakete von den zugrundeliegenden Betriebssystemfunktionen zu einem Paket zusammengefasst werden.

Ich habe in meinem eigenen Client-Code das Problem folgendermaßen gelöst. Die TCP-Verbindung wird dabei als Datenstrom behandelt.
  1. Warte, bis mindestens 4 Bytes eingetroffen sind.
  2. Lese genau 4 Bytes als Längenangabe (L).
  3. Warte, bis mindestens L Bytes eingetroffen sind.
  4. Lese genau L Bytes.
  5. Interpretiere die L+4 Bytes als ein Paket.
  6. Gehe zu 1.
Die jeweils zusätzlich eingetroffenen Bytes werden ignoriert. Auf diese Weise spielt die tatsächliche Paketaufteilung keine Rolle.

Gruß,
- Christopher

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Komische Daten vom Server

#12 Beitrag von protonmw (Marc) »

@Immo: Habe hier das Snifferfile. Ist Wireshark :D
EDIT: das mit der Geschwindigkeit habe ich noch nicht probiert

@Christopher: Genau so hab ichs gemacht. Hab das cppFile ebenfalls hier...

http://allewatschi.de.vu/
Zuletzt geändert von protonmw (Marc) am 17.09.2009 12:51:32, insgesamt 1-mal geändert.
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

ImmoBirnbaum
Beiträge: 1040
Registriert: 18.01.2004 12:51:32
Aktuelle Projekte: Objektbau in LOD0, Fahrpult, new adventures in VHDL
Wohnort: EPD

Re: Komische Daten vom Server

#13 Beitrag von ImmoBirnbaum »

Ich habe die PCAP-Datei mal eben angesehen, und bin jetzt noch nicht dazu gekommen, meine Vermutung morgen mal mit meinen Microcontrollern zu testen, aber unter Umständen liegt das merkwürdige Verhalten an folgendem Umstand:

Paket Nr. 4 in der Liste ist der erste Schritt der Anmeldung. Paketlänge, Protokoll-Version, Typ und Ident-String samt länge sind OK. Der TCP-Server quittiert in Paket 5 den ersten Schritt (Längenangabe 3 Bytes plus 00 02 00 als Daten).

Danach folgt in Paket 6 die Anforderung der Daten, Länge 5 Bytes stimmt, 00 03 = NEEDED DATA, 00 0A = Befehlsvorrat, 0x10 = Fahrstufe.
Die Quittierung kommt in Paket 7: 3 Bytes Längenangabe + 00 04 00 = ACK_NEEDED_DATA.

Paket 8 enthält nur das ACK des Clients für das letzte erhaltene TCP-Paket, es sind in diesem Paket keine Nutzdaten vom Client an den Server enthalten. Paket 9, das kann man auch dank des Zeitlichen Versatzes von ca. 30 Sekunden ggü. Paket 8 erkennen, enthält erstmals Daten vom TCP-Server, inzwischen wurde also Zusi angemeldet.

Ab Paket 9 kann in den weiteren Paketen mit ungerader Nummer das beschriebene Phänomen beobachtet werden: zu Anfang kommen zumindest halbwegs plausible Daten (in den Paketen mit 11 Bytes Nutzdaten), danach kommen entweder die leere Datensätze mit 02 00 00 00 00 0A, die doppelten leeren Datensätze (also 2x 02 00 00 00 00 0A hintereinander) oder einmalig in Paket 25 die Mischung aus einem Leerdatensatz und einem gültigen Datensatz (mit Fahrstufen-Wert 0).

Es könnte nun sein, dass der Knackpunkt auf Höhe von Paket 7 liegt, denn im Grunde ist die Anmeldung noch nicht abgeschlossen, wenn das erste Datenpaket (9) kommt: nach Paket 7 (00 04 00) müsstest Du lt. Protokoll-Doku die Anmeldung noch durch das Quittieren der Datenanforderung abschließen, also ein Paket mit folgendem Inhalt an den Server schicken: 04 00 00 00 als Längenangabe, weitere Daten sind dann 00 03 00 00, lt. Doku der letzte Befehl der NEEDED_DATA-Sequenz.

Wie gesagt, ich konnte noch nicht testen, wie sich meine Platinen ohne diesen Befehl verhalten, aber in meiner Firmware ist er drin und ich bin der Meinung, ihn auch zuerst übersehen zu haben und ebenfalls diese seltsamen Pakete bekommen zu haben. Das ist zumindest das einzige, was mir jetzt so beim Durchlesen aufgefallen ist.
SAAB - more than a car

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Komische Daten vom Server

#14 Beitrag von protonmw (Marc) »

Hallo Immo,

ich glaube ich verstehe was du meinst. In der "Samplesession" -Datei ist das so wie du es sagst dargestellt. Leider steht davon aber nix in der Beschreibung für ACK_NEEDED_DATA bzw. NEEDED_DATA.

Bin nur leider noch nicht dazugekommen das zu testen. Werde mich melden...

Danke Schonmal! :rofl
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Komische Daten vom Server

#15 Beitrag von protonmw (Marc) »

Also...

Lange nichts mehr passiert. Aber jetzt sitz ich wieder dran und habe immernoch Probleme mit dem korrekten Anmelden am Server.

Wenn ich mit Wireshark den Anmeldevorgang des ZusiDisplay_2_3_7 611/612 Displays mitschneide stutze ich bei folgendem:
Das Paket mit NEEDED_DATA hat 66 Databytes on wire und in der Längenangabe steht 42h = 66d !!! :sure
Letztes Byte ist 6B = PZB Zwangsbremsung.

Das nächste Paket geht nochmal an den Server mit dem Inhalt: 08 00 00 00 00 03 00 00
Also wieder eine falsche(?!) Länge.

Bin jetzt völlig verwirrt... :angst
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

Re: Komische Daten vom Server

#16 Beitrag von Andreas Karg »

Passt doch alles. 66 Databytes und eine angegeben Länge von 66. Oder was? Soweit ich mich erinnere gilt die Längenangabe für das komplette Paket mit Befehl und Parametern, und ich glaube, auch der Längenangabe.

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Komische Daten vom Server

#17 Beitrag von protonmw (Marc) »

Eben nicht! Bei den Kommandos 00 01, 00 02, 00 03 und 00 04 steht in der Doku "Länge des nachfolgenden Datenpakets in Byte (Cardinal, Intel-Order)" also die 4 Byte der Längenangabe rausgerechnet. Und so kommts auch übers Netzwerk.
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

Re: Komische Daten vom Server

#18 Beitrag von Andreas Karg »

Also. Ich hab es grade in meiner Implementation nachgeguckt. Die Längenangabe ist ohne die 4 Byte der Längenangabe selber und es funktioniert einwandfrei. Ich könnte mir vorstellen, dass der TCP-Server die Needed-Data-Anforderungen in dem Moment bearbeitet, wo sie reinkommen und nicht auf den Abschluss des Pakets wartet. Da vom Client laut Protokoll nach dem Needed-Data-Befehl nichts mehr kommt, wartet der Server halt vergeblich auf das Ende des Pakets und sendet derweil die schon angeforderten Daten.
Nimm zum Sniffen doch mal lieber meinen Soundthesizer her. Dessen Netzwerkteil ist eins zu eins von der Schuhmann'schen Referenz übernommen. Wenn's da auch nicht stimmt, bin ich ratlos.

protonmw (Marc)
Beiträge: 300
Registriert: 06.05.2009 10:59:49
Wohnort: Freiberg(Sachs)

Re: Komische Daten vom Server

#19 Beitrag von protonmw (Marc) »

Hallo,

habs jetzt soweit hinbekommen, dass es geht! Ich lasse mir den LM Zugart O anzeigen indem ich einfach die Schrift "85" darstelle oder eben nicht. Klappt soweit!
ABER: wenn ich nicht lokal sondern auf nem 2. Rechner mein Programm starte, dann kommen die Daten irgendwie nur noch sporadisch an.

Bsp: PZB Restriktiv: lokal blinkt meine Schrift 1:1 mit dem LM - auf dem 2.PC geht manchmal nur jedes 3.-4. Blinken mit... ;(

Hat jemand sowas schonmal beobachtet?

EDITH meinte, ich solle noch sagen, dass beide Rechner per 100Mbit Switch verbunden sind.
Zuletzt geändert von protonmw (Marc) am 24.02.2010 08:49:53, insgesamt 1-mal geändert.
MfG Marc

"Wir genießen das Leben in vollen Zügen!"

ImmoBirnbaum
Beiträge: 1040
Registriert: 18.01.2004 12:51:32
Aktuelle Projekte: Objektbau in LOD0, Fahrpult, new adventures in VHDL
Wohnort: EPD

Re: Komische Daten vom Server

#20 Beitrag von ImmoBirnbaum »

Ich habe zumindest ein sehr instabiles Verhalten der PZB-Leuchtmelder (Aussetzer, verpasste Ein/Aus-Wechsel) an meiner Fahrpult-Elektronik beobachten können, wenn der TCP-Server nicht auf dem selben Rechner wie der Simulator läuft. Das könnte aber auch daran liegen, dass ich den TCP-Server auf meinem alten 800 MHz-Laptop habe laufen lassen. Läuft der TCP-Server parallel zum Simulator auf meinem 1.8 GHz Centrino-Laptop, dann kommt es nicht zu solchen Aussetzern. Ich habe noch nicht weiter untersucht, ob das daran liegt, dass Server und Zusi nicht auf dem selben Rechner laufen, oder ob das an der flauen Performance des alten Laptops liegt.

Ist evtl. bei den von Dir verwendeten Rechnern auch ein etwas älteres Modell dabei?
SAAB - more than a car

Antworten