PDA

View Full Version : TCP/IP



DEVJO
23-11-04, 12:44
Hallöchen an alle,

wir haben wieder mal in kleines Problem in der TCP/IP Kommunikation.
Wir schicken neuerdings einen "Kom. Kopf" vor unseren eigentlichen Daten, welcher im Binären Format die Länge der einzulesenden Daten übermitteln soll und dieses auch tut. Soweit so gut, es klappt auch recht gut, aber...... teilweise bleibt die Anwendung einfach stehen, als ob der Port abgeschaltet wurde. Man muss dann die Serveranwendung neu starten, damit es wieder funktioniert. Hat jemand eine Ahnung, was die Ursache sein könnte? Vorher, ohne diesen Kopf, hat es wunderbar funktioniert.
Ich bin für jeden Tip dankbar

BenderD
23-11-04, 13:23
Hallo,

ein wenig mehr Info bräuchte man schon, was ihr da treibt und welche Symptome ihr dann habt...

mfg

Dieter Bender


Hallöchen an alle,

wir haben wieder mal in kleines Problem in der TCP/IP Kommunikation.
Wir schicken neuerdings einen "Kom. Kopf" vor unseren eigentlichen Daten, welcher im Binären Format die Länge der einzulesenden Daten übermitteln soll und dieses auch tut. Soweit so gut, es klappt auch recht gut, aber...... teilweise bleibt die Anwendung einfach stehen, als ob der Port abgeschaltet wurde. Man muss dann die Serveranwendung neu starten, damit es wieder funktioniert. Hat jemand eine Ahnung, was die Ursache sein könnte? Vorher, ohne diesen Kopf, hat es wunderbar funktioniert.
Ich bin für jeden Tip dankbar

DEVJO
23-11-04, 13:30
Hallo Herr Bender,

wir nehmen Daten an und leiten die mit unserem Programm lediglich weiter an andere Veranstalter und /oder in unsere eigentliche Anwendung leitet. Vielleicht erinnern Sie sich, wir haben das Server Programm gemeinsam hier erstellt. Damals haben wir eine feste Länge voraus gesetzt, die pro Datensatz kommt. Dies hat sich nun natürlich geändert. So das wir jetzt jedem Datensatz besagten Kopf voran stellen, d.h. wir lesen einmal 6 Zeichen ein in diesen 6 Zeichen ist die Länge auf den letzten beiden Zeichen binär verschlüsselt, zusätzlich haben wir noch andere Angaben in diese 6 Zeichen "gepackt" unter anderem ob Zusatzdaten kommen,die Länge der Zusatzdaten, um dann anhand der übermittelten Länge den eigentlichen Datensatz einzulesen.
Teilweise geht es auch durch, aber in einigen Fällen, die wir nicht näher beschreiben können (da wir sie nicht identifizieren können), nimmt das Programm keine anfragen mehr an.

BenderD
23-11-04, 13:42
Hallo,

das war doch was mit einem Socket Connect, im TCP IP sollte das eigentlich nicht liegen, dann wäre das m.E. ein Bug im Betriebssystem (PTF?); das sieht eher nach einem Problem auf Application Level aus. Wie oft tritt das denn auf? hat man da hinreichende Chance das mit einem communication Trace zu fangen? wie sieht's mit Fehlermeldungen aus? in welchem Status sind sendendes/empfangendes Programm? Man sollte mal ausführliche Diagnostic Ausgaben in die Programme einbauen, um den Fehler einzukreisen.

mfg

Dieter Bender


Hallo Herr Bender,

wir nehmen Daten an und leiten die mit unserem Programm lediglich weiter an andere Veranstalter und /oder in unsere eigentliche Anwendung leitet. Vielleicht erinnern Sie sich, wir haben das Server Programm gemeinsam hier erstellt. Damals haben wir eine feste Länge voraus gesetzt, die pro Datensatz kommt. Dies hat sich nun natürlich geändert. So das wir jetzt jedem Datensatz besagten Kopf voran stellen, d.h. wir lesen einmal 6 Zeichen ein in diesen 6 Zeichen ist die Länge auf den letzten beiden Zeichen binär verschlüsselt, zusätzlich haben wir noch andere Angaben in diese 6 Zeichen "gepackt" unter anderem ob Zusatzdaten kommen,die Länge der Zusatzdaten, um dann anhand der übermittelten Länge den eigentlichen Datensatz einzulesen.
Teilweise geht es auch durch, aber in einigen Fällen, die wir nicht näher beschreiben können (da wir sie nicht identifizieren können), nimmt das Programm keine anfragen mehr an.

JustMe
23-11-04, 13:47
binäre Daten einfach so per Tcp/Ip zu übertragen, ich weiss nicht, klingt wie "asking for trouble".

Warum nicht in "pure Ascii"? Auf die paar Bits kommts doch nicht an ;-)

DEVJO
23-11-04, 13:52
@ justme: Das Problem ist leider, das sich ein paar schlaue Leute damals diese Geschichte ausgedacht haben und es in der Touristik inzwischen zu einem Standart geworden ist. Dazu kommt, wenn wir es in ASCII übertragen, ich diese Daten dann erst noch übersetzen muss in EBCDIC, um an die Länge zu kommen, welche ich einlesen soll.

@ Bender: Das ist genau das Problem was wir haben, es gibt keine Fehlermeldung, das Programm reagiert lediglich nicht mehr auf Anfragen, es "läuft" eigentlich weiter, Status ist in Ordnung, alles okay, aber es nimmt nichts mehr an.

BenderD
23-11-04, 14:08
Hallo,

gegen Binäre Daten ist eigentlich nix einzuwenden, das geht bei Grafikdaten schließlich auch. Dafür hat man ja die tiefer liegenden Schichten, dass man das kann.
Was den Programmstatus angeht, da ist die letzte erfolgreiche Aktion interessant und die bekommt man über ein entsprechend feinkörniges (schaltbares) logging und über den Communication Trace. Eventuell sieht man schon was, wenn man so ein "untätiges" Programm mit Start Servjob unter debug nimmt und mal dumpen lässt.

mfg

Dieter Bender


@ justme: Das Problem ist leider, das sich ein paar schlaue Leute damals diese Geschichte ausgedacht haben und es in der Touristik inzwischen zu einem Standart geworden ist. Dazu kommt, wenn wir es in ASCII übertragen, ich diese Daten dann erst noch übersetzen muss in EBCDIC, um an die Länge zu kommen, welche ich einlesen soll.

@ Bender: Das ist genau das Problem was wir haben, es gibt keine Fehlermeldung, das Programm reagiert lediglich nicht mehr auf Anfragen, es "läuft" eigentlich weiter, Status ist in Ordnung, alles okay, aber es nimmt nichts mehr an.