@PicNick: Warum <char> mit <prefix><char+5> übertragen ?
Weil dann dein Kontrollzeichen mit dem Wert von char absolut eindeutig
im Datenstrom ist. Das erleichtert einige Dinge, z.B. kannst du immer
gleich feststellen, ob es sich wirklich um ein Steuerzeichen handelt.
Empfängst du ohne diese Bedingung einen char, hängt die Bedeutung immer
davon ab, ob davor eine Escapesequenz war oder nicht. Funktionell
letztendlich gleich, aber IMHO etwas flexibler zu handlen (Steuerzeichen
können vor Escapes gecheckt werden).

@PickNick:
Was ist das mit dem draufaddieren ?

@NumberFive:
Mit welchen STX/ETX/PFX hast du programmiert?
3bit oder 4 bit?
Und was nützt uns eine .exe die wir nicht haben
Und schreib doch kommentierten Source, dann hilfts uns gleich viel mehr.

@NumberFive:
Ganz wichtig: die Framegrösse muss für die Schnittstelle nach oben
gelten, 127 Bytes gelten also für die reinen Daten, ohne STX, ETX, PFX.


Wie gehts weiter ?
Tja, ich habe gerade javax.comm gedownloaded und werde damit wohl mal
die Schicht 1 für seriell implementieren. Mein Programm wird wohl erstmal
ein kruder 'Tester', der regelmässig Testframes sendet und alle empfangenen
Testframes und Debuginformationen auf der Konsole anzeigt. Wäre natürlich
prima, wenn das gleich mit euren seriellen Schicht-1en zusammenspielt.

Dann brauchen wir beizeit eine Schicht 1 für IP. Ich könnte mir hier
irgendwas wie UDP-Kommunikation auf festgelegten Ports vorstellen, mit
Rechnern die sich gegenseitig discovern. Alternativ dazu auch die
einfache Variante mit vorkonfigurierten TCP/IP Streams. Auf jeden Fall
muß da in der unteren Schicht viel automatisch gehen, die oberen
Schichten sollen ja von Kommunikationsmedium nichts mitbekommen.
Meinetwegen können wir LAN aber auch gerne erstmal schieben.

Und irgendwann brauchen wir dann eine Schicht 2+3. Da habe ich schon ein
paar ausgefeilte Ideen, die ich dann zu gegebener Zeit präsentieren werde.
Um auf PicNicks Frage mit den 'Sessions' bzw 'Login' einzugehen werde ich
schon mal ganz kurz vorgreifen:

- Eine Session wird vom Absender festgelegt und ist für den Absender eindeutig
- Eindeutig ist das Tupel (SenderAddress, SessionSequence)
- Es gibt Nachrichten ohne Session
- Es gibt Nachrichten für initiale Sessions
- Es gibt Nachrichten für Session 'follow-ups'

Eine Session baut der Absender auf, indem er eine initiale Sessionnachricht
schickt. Je nach Bedarf/Protokoll kann der Empfänger auf diese Session
einmal oder mehrfach antworten. Wann eine Session geschlossen wird, entscheiden
beide Kommunikationspartner eigenständig. Damit sind einfache Challenge-Response
Nachrichten möglich (mit Timeout für den Response) oder auch Registriermechanismen
bzw. dauerhafte Datenströme (virtuelle Debug-Konsolen)

Zur Sicherheit, bzw. 'login':
Auf Schicht 1 für LAN können wir gerne einen Login implementieren, auf den
höheren Schichten höchstens eine 'Firewall'. Das würde ich aber beides
erstmal schieben.


Ragnar