So. Ich werde definitiv eine Zwischenschicht einbauen. Es hat wirklich viele Vorteile. Sie wird höchstwahrscheinlich in PHP erstellt, also eine REST-
API. Passt auch gut, da ich eine solche schon mehrfach umgesetzt habe.
...
Mir geht es hauptsächlich darum, ob die Kommandos in der o.g. Form eine gute Idee sind, oder ob ich ein anderes System/Format nutzen sollte. Dieser String könnte auch durchaus anders aussehen, z.B. so: "/user/registerOnline/192.168.1.6".
Oder man sendet gleich ein Record bzw. json-array. Es ist halt erstmal das Problem da, dass nicht absehbar ist, wie viele Parameter übergeben werden müssen, geschweige denn ganze ObjectLists.
Wie sieht dann Dein Daten-Flow aus...
1. Optimierte Routine in Deiner Anwendung.
2. Umsetzen/Parsen in einen String.
3. String wieder als Bytes per
TCP senden
4. Bytes wieder in String konvertieren
5. String auseinander nehmen
6. Routine um aus dem String eine Anfrage zu kodieren
7. Umsetzen in JSON
8. Anfrage an PHP (
oh grusel)
9. PHP Interpretiert die JSON Anfrage
10. Wieder
SQL daraus machen
11. Am Server per
TCP anfragen
Und dann das ganze wieder zurück?
Sehen wir mal von meine Abneigung zu PHP ab... Stringanalysen sind immer langsam und Du hast zu viele Konvertierungen.
SQL ist
mir schon nicht kompakt genug... Also Übertragungen und Kommandos so knapp wie möglich halten... Besonders wenn Du diese sowieso
per
TCP Übertragen willst.
Absender, Kommando, SeekNr, DatenbankID sind bei mir 7 Byte... Wenn man jetzt noch die MTU und ggf. noch für das P2P Protokoll die Daten berücksichtig, ergeben sind 1452 Bytes für Nutzer Daten.
Das ist meine Größe für eine optimale Datenübertragung von mehreren Kommandos...
Aber vielleicht optimiere ich an dieser Stelle auf ein bisschen weit...
Also vergiss den Absatz.
Mavarik