Empfangen Sie keine HTTP-Nachrichten mit Jetty

Question

Ich verwende Embedded Jetty und Spring für Java zu Java-Kommunikation über HTTP. Mein Problem ist, dass meine Server-Anwendung normale TCP-Nachrichten auch am selben Port verarbeiten muss.

Gibt es eine Möglichkeit festzustellen, ob eine TCP-Nachricht angekommen ist, die vom Servlet nicht behandelt werden kann?

Danke für die Antworten füge ich noch einige weitere Details:

• ich den Client nicht ändern können. Der Grund dafür ist, dass die alte Version des Clients pure java tcp socket verwendet und es sich herausgestellt hat, dass der neue Server abwärtskompatibel mit dem alten Client sein muss.
• Verwenden Sie den gleichen Port
• Alte Client-Nachrichten sind kurze serialisierte Text über einfache Socket. 1: offene Verbindung, 2: Senden Sie Text, 3: enge Verbindung
• Mein Server sieht wie folgt aus: http://kielczewski.eu/2013/11/using-embedded-jetty-spring-mvc/
• Ich brauche nicht die Nachricht zu analysieren. Es genügt zu erkennen, dass eine Nachricht angekommen ist, die nicht http verwendet und den Quell-Host-Namen abruft.

Answer 1

Vielleicht möchten Sie einen Blick darauf werfen, wie Sie einen benutzerdefinierten ConnectionFactory an die ServerConnector Ihres HTTP-Ports hinzufügen.

Dieses ConnectionFactory Konzept ist, wie das PROXY Protokoll in Jetty derzeit unterstützt wird.

In Ihrem Fall, Sie könnten wie etwas ...

MyTcpConnectionFactory tcpConnectionFactory = new MyTcpConnectionFactory(); 
ServerConnector http = new ServerConnector(server); 
http.addFirstConnectionFactory(tcpConnectionFactory); 
server.addConnector(http); 

In Ihrem Fall würden Sie die newConnection(Connector connector, EndPoint endPoint) Methode außer Kraft setzen und die Prüfung für Ihren TCP-Fluss oder den HTTP-Flow implementieren.

Wenn es Ihr Fluss ist, behandeln Sie die Kommunikation auf dieser Verbindung selbst und dann eine IOException, wenn Sie fertig sind, dass Sie nicht möchten, dass Jetty diese Verbindung als HTTP verarbeitet.

Andernfalls geben Sie das Connection-Objekt an Jetty zurück, um es als HTTP zu verarbeiten.

Answer 2

Sie sind hier für eine wilde Fahrt hier mein Freund. Sie müssen erkennen, dass HTTP IS TCP ... nur der Inhalt ist, der über den TCP-Socket gesendet wird, der ihn als HTTP klassifiziert oder nicht. Davon abgesehen, können Sie die Verbindung mit einem Filter dh

1 abfangen) einen Filter (Google Java Application Server-Filter erstellen und die Jetty Implementierung überprüfen) für alle eingehenden Verbindungen

2) prüfen URI auf Antrag wenn es fehlschlägt, dann ist die Anforderung nicht HTTP (könnte auf Wunsch Testlogik hier verdoppeln wollen überprüfen)

3) Schalten sie die neue Anforderung an den entsprechenden Servlet/Funktion basierend auf einer seriellen Buchse/HTTP-Anfrage

In einem anderen Hinweis, warum nicht https (Port 443) für http und Port 80 für Ihren Socket verwenden Anforderungen?

---

Ich stehe korrigiert. Filter funktionieren nicht. In diesem Fall müssen Sie eine Mini-Firewall codieren. Sie müssen alle Eingaben für https-Header scannen und entsprechend umleiten. Können Sie zumindest einen Kontext für die reinen TCP-Nachrichten bereitstellen, die Sie erhalten möchten? Haben Sie eine Kontrolle über den Sendecode? Sie wissen, dass Sie eine TCP/HTTP-Verbindung zu einem Websocket (involvieren Client und Server) aktualisieren können und es funktioniert sogar noch besser als einfaches TCP, gleiche Port-Verbindungen, und kommt in Jetty, so dass keine benutzerdefinierten Kesselplatten, nur ein Websocket-Servlet