HTTP Streams setzen

[v Ralle v]

Guten Abend,

ich glaube, dass ich ein sehr spezielles Problem habe, daher kam ich bei Google auch nicht weiter. Folgendes: bei meinem Programm kann man eine Verbindung sowohl über Sockets als auch über Bluetooth herstellen. Für Bluetooth verwende ich die Bluecove Bibliothek.

Das Problem ist: ich würde gerne bei beiden Verbindungen HTTP als Protokoll verwenden (da Firewalls hier weniger Probleme bereiten), aber bei Bluetooth bekomme ich nur einen InputStream und einen OutputStream. Ich kenne aber keine Bibliothek, wo ich den Stream setzen kann.

Auch sollte die Verbindung dauerhaft bestehen. Das sollte doch mit einer persistenten Verbindung möglich sein?

Gibt es für mein Problem eine Lösung?

Ich habe auch überlegt, die Verbindung über Interfaces zu abstrahieren und TCP und Bluetooth unterschiedlich zu implementieren, da sie sich doch ziemlich stark unterscheiden. Würdet ihr mir das eher raten? Da habe ich allerdings wieder das Problem, dass ich ziemlich viel Code doppelt schreiben muss.

Ich danke für jeden Tipp.

 

[troll]

also ich weis jetzt nicht ob man über bluetooth TCP legen kann ... aber HTTP ist für persistente verbindungen das falsche protokoll ...
es gibt zwar das sog. HTTP-keepalive ... das ist aber weniger für persistente verbindungen gedacht sondern eher dafür das über eine verbindung mehreren anfragen hintereinander gestellt werden können um die geschwindigkeit zu steigern ... (hat was mit TCP slow start und dem ständigen connecten und trennen mit einem HTTP server zu tun)

außerdem hat HTTP in dem sinne eher weniger was mit firewalls zu tun außer das HTTP halt festlegt : TCP/80
intiligenten firewalls ist das aber ziemlich egal da diese auch prüfen von welchem prozess aus der socket kommt ... und wenn als source nun mal java steht ist es der firewall egal das TCP/80 HTTP ist ... es muss trotzdem freigegeben werden ... vor allem bei eingehenden verbindungen ...

 

[v Ralle v]

Ok, ich verstehe.

Du würdest mir also davon abraten und stattdessen empfehlen, selber ein Protokoll zu implementieren?

 

[troll]

wenn du jetzt nicht auf einer / beiden seiten einen HTTP-server laufen lassen willst dann würde ich dir auf jeden fall zu einem eigenen protokoll raten ...

nach dem was mir google mal so eben gesagt hat verwendet blueooth PAN/BNEP .. BNEP ist wohl irgendwie eine "emulation" von ethernet ... PAN ist eine darauf aufbauendes protocol wie z.b. IP ...
demnach müsste man auch IP für BNEP zum laufen bekommen und darauf ganz normal TCP/IP laufen lassen können ...

es gibt ein beispiel für unix in dem der bluetooth-schnittstelle eine IP zugewiesen wird ...
dieses beispiel geht davon aus das man dies auf beiden seiten macht um eine IP-verbindung zu ermöglichen ..

wenn du also mit dem punkt "bluetooth" auf modile geräte anspielst müsste jedes gerät das die software verwendet soweit modifiziert werden das man rechte bekommt einem netzwerk-adapter eine adresse zu vergeben ... allgemeinhin bei smartphones als "rooten" bekannt ...

da du allerdings sagtest das du wenigstens an Streams kommt kannst du damit arbeiten ...
ist zwar ziemlich low-level, aber ich denke anders wird es nicht gehen ...
vielleicht könnte man noch einen eigenen FilterStream schreiben der mit dem bluetooth-protocol kompatibel ist ... ist aber einiges an arbeit

 

[v Ralle v]

Danke für die Mühe, dann werde ich mich für ein eigenes Protokoll entscheiden.

Zu viel Magic mit dem Zuweisen von IPs kann ich halt nicht machen. Ich wollte halt gerne Meinungen von anderen, wie sie vorgehen würden. Daher hat das mir geholfen!

 

[tuxedo]

Um das Problem mit der persistenten HTTP Verbindung zu lösen: Wie wär's mit Websockets? Die sind doch genau dafür erfunden wurde?!

- Alex

 

[v Ralle v]

Darüber hatte ich mich schon informiert. Es bringt mich für mein Problem aber nicht weiter (Bluetooth). Wenn ich Websockets richtig verstehe, werden, nachdem eine Verbindung aufgebaut wurde, auch nur Nachrichte hin und her geschickt. Da muss der Entwickler sich wieder sein eigenes Protokoll ausdenken.

Korrigiert mich bitte, falls das falsch ist.

Für die persistente Verbindung wäre es sicher eine Lösung, da es auch gute Bibliotheken zu geben scheint.

 

[tuxedo]

Wenn die Websocket-Verbindung steht, ist das wie eine persistente, bidirektionale Stream-Verbindung. Da kannst du alles möglich drüber laufen lassen. Ein Protokoll brauchst du so oder so, und so wie ich dich verstanden hatte, wolltest du HTTP nicht wegen des Protokolls an sich, sondern weil es so einfach mit Router und Firewalls harmoniert. Über Websockets kannst du i.d.R. auch jedes andere Protokoll transportieren.

Was willst du denn über die Leitung schicken? Vielleicht kann man hier einen Protokoll-Tipp abgeben...

- Alex

 

[v Ralle v]

An Daten werden Strings, Integer und Bilder (als byte Array) verschickt. Bisher habe ich ein Protokoll, was noch aus den Anfängen meiner Programmierung stammt.

Im Prinzip wurde immer versendet: Was wird gesendet (feste Anzahl an Kommandos) und der entsprechende Wert. Dazu habe ich einen DataInputStream verwendet, da die primitiven Datentypen und Strings sehr simpel abgedeckt sind.

Allerdings kam es auch ab und zu vor, dass sich die Kommunikation verhaspelt hat und hängen blieb (meist bei den Bildern).

Nun wollte ich das ganze aufräumen. Das Datenformat wird JSON, das steht egtl schon fest.

Jetzt mal Bluetooth vernachlässigt: wenn ich über Websockets statt normalen Sockets verwende, dann werden mit Router seltener einen Strich durch die Rechnung machen?! Die initiale Verbindung ist ja das Hauptproblem.

 

[tuxedo]

Im Prinzip wurde immer versendet: Was wird gesendet (feste Anzahl an Kommandos) und der entsprechende Wert. Dazu habe ich einen DataInputStream verwendet, da die primitiven Datentypen und Strings sehr simpel abgedeckt sind.

Habe ich früher auch oft verwendet. Hat immer problemlos und zuverlässig geklappt.

Allerdings kam es auch ab und zu vor, dass sich die Kommunikation verhaspelt hat und hängen blieb (meist bei den Bildern).

Kleiner Bug im eigenen Protokoll?

Nun wollte ich das ganze aufräumen. Das Datenformat wird JSON, das steht egtl schon fest.

Spielt Protokolloverhead eine Rolle? Was kommen da pro Client an Datenmengen zusammen?

Jetzt mal Bluetooth vernachlässigt: wenn ich über Websockets statt normalen Sockets verwende, dann werden mit Router seltener einen Strich durch die Rechnung machen?! Die initiale Verbindung ist ja das Hauptproblem.

Ich hab Websockets bis dato nicht selbst eingesetzt, nur viel dazu gelesen und Demos angeschaut. Aber ja, das ist die Idee hinter Websockets: Bi-Direktionale, persistente Verbindungen da da, wo sonst HTTP läuft. Beim Verbindungsaufbau macht ein CLient eine Socketverbindung zum Server auf, kommuniziert mit HTTP zum Server dass er gerne Websocket nutzen möchte und der Server tut dann das nötige um die Verbindung offen zu halten.

Websockets haben, wie ich finde, aktuell nur einen Schönheitsfehler, der wohlmöglich bald durch passende Plugins etc. gelöst wird:

Man braucht einen Webserver. Okay, das ist jetzt noch nciht das Problem. Aber in meinem Einsatzgebiet hab ich meist eine stand-alone-serveranwendung welche für sich lebt und eben von aussen über Sockets Verbindungen unterhält. Will man sowas nun bei einem Kunden mit Websocket laufen lassen dann ergibt sich meist das Problem: Der Websocketserver muss an einer öffentlichen IP lauschen. Und oftals gibt's nur eine öffentliche IP, und da lauwscht eben schon auf 80 und 443 ein (Apache) Webserver.

Was jetzt fehlt ist ein passendes Modul/Plugin das man dem Webserver unterjubelt, welches eingehende Websocketverbindungen auf http://meintollerwebserver.de/meintolleswebsocketprojekt/xyz/foobar entgegen nimmt und (z.B. mit einer normalen Socketverbindung) intern an die dedizierte Serveranwendung in die DMZ weiterreicht.

Hab im Falle von Apache von einem in Python geschriebenen Plugin gelesen dass sowas können soll. Aber das scheint noch experimentell zu sein?!
Wer mehr weiss darf mich gerne erleuchten.

- Alex

[EDIT]Using apache-websocket to proxy tcp connections | Alex Bligh's blog[/EDIT]

 

[v Ralle v]

Dein angesprochenes Problem habe ich nicht, da meine Applikation auf einem Heim-PC laufen soll. Ich wäre verwundet, wenn dort der Port schon belegt ist (ausweichen wäre im Notfall auch möglich).

Die Hänger konnte ich mir selber nicht erklären, da sie nicht reproduzierbar waren. Sie waren auch wirklich selten. Bei den byte Arrays habe ich immer erst die Länge des Arrays geschickt und dann das Array selber (ähnlich zu Content-Length). Aber manchmal schien noch was im Stream beim Lesen zurück zu bleiben, was den DataInputStream dann gestört hat und zu den Hänger geführt hat. Ich hätte den Stream sozusagen vor der nächsten Leseoperation "reinigen" müssen.

Ich werde jetzt wahrscheinlich komplett auf JSON umsteigen und weiterhin den DateInputStream für den String verwenden, da er sonst problemlos funktioniert hat. Nur bei dem Misch-Masch gab es in seltenen Fällen das Problem. Dies will ich nun beseitigen.

Die Datenmenge hängt vom Anwender ab, kann ich schwer einschätzen. Der Protokolloverhead spielt eine kleinere Rolle, solange die Kommunikation stabil ist.