HTTP Tunneling

Roman007

Hallo,
ich habe in Rahmen einer Diplomarbeit die Aufgabe, die Simulationsdaten eines Roboters im Browser darzustellen. Die Daten werden von einer Anwendung (c++) gelesen und sollten im Internet abrufbar sein und als 3D Modell dargestellt werden.
Bis jetzt habe ich die Kommunikation über Sockets abgewickelt. (Applet als Client)
Jetzt teilt mir mein Prof mit, dass ich (wegen Web Server - Tomcat) nur Port 80 zu Verfügung habe.
Ich nehme mal an, dass mir nichts anders übrig bleibt als einen Servlet zu schreiben, der die Daten im HTTP Protokoll verpackt, oder?
- Kann ein Servlet eine Benutzeroberfläche haben (sprich ein Frame, wo ich alle Aktivitäten des Servlets überwachen kann) ?
- kann ich Servlet gleich nach dem starten des Tomcat-Server initialisieren?
So wie ich getestet habe, wird die init() Methode erst nach der Client Anfrage gestartet. Ist das richtig?(Anwendung Statusfenster des Tomcats zeigt, dass Servlet gestartet ist)

Noch eine letzte Frage: HTTP ist doch ein Datagramm- Protokoll, korrekte Übertragung wird damit nicht garantiert, ist das korrekt? TCP (mit Sockets)
dagegen schon.

ich hoffe, Ihr könnt mir etwas auf die Sprünge helfen

Grüße
Roman

HTTP ein Datagramm-Protokoll?

HTTP basiert doch auf Sockets, oder...

Zu der Binärübertragungsfrage:

Ich habs noch nicht selbst ausprobiert, aber du kannst doch
ne Klasse schreiben, die von javax.servlet.GenericServlet ableitet.
In der Metohode service(ServletRequest req, ServletResponse res)
kannst du im res, dann mit getOutputStream auf den OutputStream zugreifen.

Ich denke nicht, dass der irgendwelchen zusätzlichen Daten sendet.

Kannst ja mal schreiben, ob das geklappt hat...

Grüße von der Uni Dortmund,
Uni Do-ler

megaweber

HTTP basiert auf TCP!
Also die Daten kommen sicher an !

Roman007

Danke für die Antworten,
ihr habt natürlich recht , was das HTTP Protokoll angent.
Eine meiner Fragen habe ich schon im Buch "Developing Java Sevlets" gefunden, nämlich die init() Methode wird beim ersten starten des Servlets ausgeführt.

@Uni Do-ler
so wie du mir empfohlen hast perfect funktioniert, mit einer Kleinigkeit: wenn man ein Object im HTTP- Tunnel als ObjectOutputStream versenden will muss die zu versendene Klasse Interface "Serializable" implementieren.

Hier ein Code Auschnitt:

[code]public class curData implements Serializable {

// Klasse, die versendet werden soll

} 
[/code]

und dann die überschriebene service Methode des Servlets (Ausschnitt):

[code]
public void service (HttpServletRequest req,HttpServletResponse res )
				throws ServletException ,      IOException{

curData data;

 try {
// hier evtl. Input-Stream behandlung

    	 // Die Server Antwort beginnt hier
    	 // Object "data" der Klasse  "curData" wird an Clienten gesendet 

    	 res.setContentType("application/octet-stream");

    	 ObjectOutputStream os = new ObjectOutputStream (res.getOutputStream());
    	 os.writeObject(data); 
    	 os.flush(); 
    	 os.close(); 	 
     } 
 	} catch (Exception e) {}
}
[/code]

Eines hätte ich noch gewußt, wie kann ich die Aktivitäten des Servlets z.B. durch einfache System.out.println() zum Debug Zwecken überwachen?

Hat jemand Lösung ?

Danke im voraus

Roman

Wenn du die Objekte versenden willst, muss die Klasse natürlich Serializable implementieren. Evtl. würde ich noch Felder transient machen.

Wenn du den Tomcat per Konsole startest, solltest du die Ausgaben sehen...
Ansonsten kann ich dir Log4j empfehlen, dann schreibst du die Ausgaben in eine Datei...

Wäre doch möglich das DU eine 2 Applikation schreibst als Server dieser gibt nur Meldungen aus die Clients ihm schicken. Eine Art Server der Debbuging-Informationen anzeigt.

In dem Servelet schickst Du über UDP aus jeder Methode die Dich interessiert
und die neuralgisch ist Nachrichten an diesen Server. So kannst Du über dieses
Programm das verhalten des Servlet verfolgen. Kenne mich jetzt nathürlich nicht
so mit den Sichheitseben bei Http-Servern aus und ob die es irgendwie zulassen können das sich Servelets ihrerseits mit anderen host verbinden dürfen.
Vielleicht wäre es auch möglich das das Servlet Datezugriffsrechte auf dem Http-Server erhalten kann dann könnte das Servlet dort zumindest Informationen loggen.

Müsste doch eigentlich machbar sein.

P.S.: Da dein Servlets HTTP-Server erweitern wird es aus Gründen der Sicherheit
und den beschränkten Zugriffen villeicht schwierig Nachrichten einfach
auf die Console zu schicken. Denke ich. Servlets sind ja keine
Consolenprogramme. Ganz ähnlich ASP. Das läuft alles in der Sandbox des
Http-Server der darüber mit Funktionalität erweitert wird.

Wie man Servlets debuggen kann, so zumindest die Info über diesen Link
Http Tunneling
Debugging mit dem TCPmonitor
Und nochwas zu Debugging Servlets Java Webservices

Roman007

@sclearscreen
Danke für die Links.
Alos ich benutze schon seit längere Zeit Eclipse 3.1, Tomcat - Plugin für Eclipse habe ich auch installiert. Beim starten des Tomcats über Eclipse wird die Console angezeigt, aber nur das Starten, Beenden und evtl. interne Fehlermeldungen des Servers. println leider nicht.
habe etwas anderes versucht: aus der init() Methode des Servlets ein neues Frame erzeugt. Klappt sogar, aber nur wenn über Eclipse starte,tue ich das direkt über "Tomcat Monitor" wird das Fenster nicht angezeigt, aber auch keine Fehlermeldung.
Merkwürdig Wo ist der Unterschied ?

sclearscreen schrieb:

P.S.: Da dein Servlets HTTP-Server erweitern wird es aus Gründen der Sicherheit
und den beschränkten Zugriffen villeicht schwierig Nachrichten einfach
auf die Console zu schicken. Denke ich. Servlets sind ja keine
Consolenprogramme. Ganz ähnlich ASP. Das läuft alles in der Sandbox des
Http-Server der darüber mit Funktionalität erweitert wird.

Dazu kann ich mich mal selbst zitieren.
Dein Servlet ist ja auch kein Programm was eine Konsole braucht
bei einem richtigen Konsolenprogramm werden ja auch gleichzeitig 3 Filehandle bereitgestellt

STDIN
STDOUT
STDERROR

wäre sowas bei Servlets dabei würde dies an den Sicherheitskonzepten eines Webserver vorbeiwirtschaften! Eben ähnlich wie bei IIS, Apache auch.
Zumal wenn man einen Rechner stehen hat der als Webserver fungiert wird
dieser höchstens über eine Shell konfiguriert und gewartet, es hat überhaupt keinen Sinn für jedes Servlet was ein User über Internet anfährt auch eine Konsole bereitzustellen aus Sicherheitsgründen.

Servlets, ASP-Seiten, CGI-Skrpte etc. sind halt nur Module die dazu da sind
dynam. HTML zu generieren damit der Nutzer was auf seine Browser angezeigt bekommt.

Hast Du Dir die Links mal angeguckt da ist doch auch ein Beispiel dabei über Servlets den TOMCAT und Debugging.

Da ist etwas Einfallsreichtum beim Debugging gefordert. Verifizier dochmal
ob Du ein JAVAKonsolenprogramm, was Du erstellt hast, über die Wartungskonsole
des Server (Webserver wo dein Servlet mal arbeiten soll) zum laufen zu bewegen. Dieses Programm würde ich auf eine Socket lauschen lassen. So nun spielst Du noch auf dem Server dein Servlet ein.
Im/aus dem Servlet heraus schickst Du an dieses eine Programm Informationen (zum Debugging). Damit Du siehst ob alle Methoden des Servlet funktionieren
gehst Du wieder an die Wartungskonsole des Webserver und beobachtest das Programm!

Du bittest Nun noch einen netten Kollegen das Servlet mal anzufahren
(er soll sich mit dem Webserver per Browser verbinden), er soll auf den Seiten
die euer Webserver anbietet mal rumsurfen. So dann müstest Du an der Konsole sehen ob dein selbstgeschreibenes Wartungsprogramm Nachrichten von Deinem
Servlet erhält. Funktioniert alles brauchst Du dann Deine Wartungscode im Servlet nur noch rauswerfen oder ausdokummentieren.

Und zum anderen hast Du doch noch den Link über das Programm TCPmonitor.
Das sollte Dir doch dann die Möglichkeit in die Hand geben das zu bewerkstelligen.

Ja ich schaffe zwar auf Basis von ASP bei meinem IIS aber die Konzepte und Funktionalität zu Servlet gleichen sich doch.
Achja was sagt mir meine Erfahrung noch? es ist auch ganz nützlich wenn es mal ganz knifflig ist solche Webservermodule zu debuggen, nimmt man sich einen
Netzwerksnifferprogramm und guckt damit was auf dem Netzwekadapter abläuft.

Zu diesem Zweck habe ich mir hier auf meine WinDose Ethereal gezogen.

Roman007 schrieb:

direkt über "Tomcat Monitor" wird das Fenster nicht angezeigt, aber auch keine Fehlermeldung.
Merkwürdig Wo ist der Unterschied ?

Irgendwo bei dem Links von mir stand was zu Debugging von Servlet und Tomcat.
Zum anderen hilft da auch nur mal in einem Manual über Tomcat zu lesen.

Leider mehr Ideen und Vorschläge fallen mir dazu jetzt auch nicht ein.

Sorry!

Gruss sclearscreen

P.S.: Wie man den Tomcat zum Remote Debugging bewegt

Und Remote Debugging bedeute du verbindest Dich mit Deiner IDE zu dem zu dbuggenten Prozesse.

Roman007

hallo ,da bin ich wieder
Danke euch Leute,
inzwischen habe ich Lösung gefunden, denke mal die Einfachste.
Man kann direkt aus der Servlet Klasse dh., die von Servlet abgeleitet ist, keine Konsolen, oder Frames oder Dialogfelder erzeugen. Aber man sich in Servlet ne neue Klasse erzeugen, und daraus z.B. Frame mit allen möglichen Steuerelementen bauen. Also doch Servlet mit Benutzeroberfläche
Übrigens, daraus funzt auch die Konsolenausgabe in Eclipse.
z.B so:

[code]
public class myServlet extends HttpServlet {

	private hilfsClass = new hilfsClass() ;
.
.
public void eineMethode(){
    hilfsClass.appendToDisplay("my Message");
} 

[/code]

und dann :

[code]
public class hilfsClass{

Frame msgFrame;  

public hilfsClass(){

msgFrame = new Frame();
// hier evtl. noch der Frameaufbau
msgFrame.setVisible(true);
}

public void appendToDisplay (String message){

System.out.println (message);
// oder 
msgArea.add(msg); // add. neuer Eintrag in die Liste
msgArea.select(msgArea.getItemCount() - 1); // letzen Eintrag markieren

}[/code]

Das Ganze hat für einen Servlet- online Betrieb keinen Sinn , aber als Debuger eine Super Idee.

Nochmal Danke

Roman

Eben finde ich auch

**
Mann macht warmes Wasser mit der Kaffeemaschine wenn wenn der Herd kaputt ist und rührt dann darüber den Kartoffelbrei an!**

An Deiner Stelle mach Dir eine Allgemeingültige SupportDebuggerHilsServeletklasse daraus und pack das Ding in Deinen Werkzeugkoffer.

Gruss sclearscreen