TAPCOM-Library zur Kooperation von TAPs

[asrael]

[quote=""ibbi""]Nur sollte der Client nicht unumstößlich daran glauben, die Improbox liefe, wenn er die ID findet. Er könnte - ohne Kommunikations-Timeout - enttäuscht werden.
[/quote]
Du bist aber sehr pessimistisch. Gottseidank haben wir ja auf dem TOPF mit Trojanern etc. tatsächlich noch nichts zu tun und das bleibt hoffentlich auch so.
Wenn zwei TAPs zufällig die gleiche ID haben (da es ja keine zentrale Stelle in Korea gibt, die diese vergeben, ist der Fall theoretisch möglich), so könnte in der Tat der Fall auftauchen, dass ich etwas von Improbox möchte, da aber in Wirklichkeit ein australisches TAP läuft.

Aber erstens ist die Chance bei dem Wertebereich für die TAP-ID relativ klein und zweitens ist es selbst dann ziemlich unwahrscheinlich, dass ein Benutzer zufällig ein TAP laufen hat, das über TAPCOM Improbox anzusprechen versucht, der Benutzer aber Improbox gar nicht verwendet, sondern zufällig dieses andere TAP mit Improbox-ID.

Sorry, aber ich finde die Diskussion gleitet etwas sehr in wenig fruchtbare "Was-könnte-im-schlimmsten-Fall-passieren?"-Szenarien ab. Wenn man schon dabei ist, ist der Fall, dass ein anderes TAP einfach sang- und klanglos die Tastatur-Ereignisse verschluckt (und damit TAPCOM lahm legt), viel wahrscheinlicher.

Aus meiner Sicht wäre die Diskussion über die "Normalfälle" und dabei auftretenden Fragen interessanter.

mfg

asrael

[ibbi]

[quote=""asrael""]Du bist aber sehr pessimistisch.[/quote]

So etwas habe ich mir beim Programmieren angewöhnt, ja.

[quote=""asrael""]Wenn man schon dabei ist, ist der Fall, dass ein anderes TAP einfach sang- und klanglos die Tastatur-Ereignisse verschluckt (und damit TAPCOM lahm legt), viel wahrscheinlicher.[/quote]

Verstehe ich die tapcom.h eigentlich richtig, dass Du keine Tastatur-Events erzeugst, sondern eigene?

[asrael]

[quote=""ibbi""]Wenn ich weiß, dass ein TAP gar nicht da ist, brauche ich erst gar keinen Speicher anfordern und kann mir die Kommunikation ersparen.[/quote]

Ja, das ist ja nur vernünftig. Aber selbst wenn das Server-TAP nach dem Prüfen und anschließenden Senden eines RPCs vom Client aus seinen Dienst einstellt und deswegen nicht mehr antwortet, könnte man so den Grund des Nicht-Antwortens einkreisen.

Aber wie gesagt: Alles eher unwahrscheinliche Szenarien, deren vollständiges Abfangen IMHO unverhältnismäßig hohen Aufwand verursacht. Hier müsste man aus meiner Sicht wenigstens mit Exceptions arbeiten können. Programmiert eigentlich jemand seine TAPs in C++?

mfg

asrael

[ibbi]

[quote=""asrael""]Hier müsste man aus meiner Sicht wenigstens mit Exceptions arbeiten können.[/quote]

Aus meiner Sicht genügt eine Zeitangabe.

[asrael]

[quote=""ibbi""]So etwas habe ich mir beim Programmieren angewöhnt, ja.



Verstehe ich die tapcom.h eigentlich richtig, dass Du keine Tastatur-Events erzeugst, sondern eigene?[/quote]

Nein, ich benutze Tastatur-Ereignisse. Diese sind laut Topfield-API-Doku die einzigen, die bei TAP_GenerateEvent zugelassen werden. Andere werden nach meinen (und wohl auch FireBirds) Tests nicht durchgereicht.

mfg

asrael

[asrael]

[quote=""ibbi""]Aus meiner Sicht genügt eine Zeitangabe. [/quote]

Ich meine eher das programmtechnische Handling.

Vorschlag: Ich behalte die Geschichte mit dem TimeOut im Hinterkopf und sehe, ob es wirklich Bedarf in dieser Richtung gibt.

mfg

asrael

[asrael]

[quote=""FireBird""]Man ackert die 16 Einträge der TAP-Tabelle durch. Jeder Eintrag, der eine gültige Adresse hat zeigt dann auf den TAP-Header und 0x0020 Bytes weiter ist eben die TAP_ID. Das mag zwar kompliziert klingen, aber ich habe fertige und firmwareunabhängige Routinen. Filer V2 markiert z.B. die aktuell laufenden TAPs in seiner Liste.[/quote]

Hi,

würdest Du mir den Code geben? Oder zumindest sagen, wie man die Startadresse der TAP-Tabelle ermittelt und welche Größe ein Tabelleneintrag hat?

Eventuell würde ich das dann in einer späteren Version von TAPCOM benutzen.

mfg

asrael