Verbinden von zwei client-sockets

Erstens, rufen Sie nicht eine akzeptierte client (server-Seite) das socket eine Client Socket. Das ist sehr verwirrend.

Lassen Sie uns sagen, wie haben zwei client-socket-Holen Sie sich miteinander, ohne Umweg über ServerSocket?

Unmöglich ist. Sie haben immer einen server-Seite, die akzeptieren, Kunden. Jetzt die Frage: welche Seite der Verbindung sollte der server-Seite?

Dinge, die Sie haben zu denken, über diese Entscheidung:

• Ein server sollte eine statische öffentliche IP-Adresse.
• Einen server, welcher nach einem router verbunden, hat zu tun "port-Weiterleitung". (Siehe UPnP)
• Ein client muss wissen, welcher host hat eine Verbindung zu (öffentliche IP)

Mitten-server

Ich sehe nicht, was Sie tun möchten, mit diesem Dritten server. Vielleicht hält der VNCServer öffentlichen IP?
*Elister* schrieb, Sie wollen eine Brücke zwischen der client-und der VNCServer. Ich sehe nicht den Vorteil von ihm.

Warum machen Sie nicht sofort eine Verbindung zum VNCServer?

Aber wenn Sie es wirklich wollen, können Sie eine situation wie diese:

 
/VNCServer (Server Läuft) <---. 
| | 
LAN -| Verbindung zum VNCServer 
| | 
\ MyApp (Server Läuft --> Akzeptiert von der Middle Server) <------. 
| 
(Über einen router) 
| 
Mittlerer server (Server Läuft --> Akzeptiert client) ---> Verbindung zu Ihrer App 
^ 
| 
(Über einen router) 
| 
Client --> Verbindet bis Mittleren Server --° 

Und das ist, wie es aussieht, ohne den Dritten server (Was ich dir empfehlen):

 
/VNCServer (Server Läuft) <---. 
| | 
LAN -| Verbindung zum VNCServer 
| | 
\ MyApp (Server Läuft --> Akzeptiert Kunden) <------. 
| 
(Über einen router) 
| 
Client --> Verbindet MyApp --------------------------° 

EDIT:

Ich denke ich hab es jetzt:

Haben wir visualisieren Ihre situation so:

 Dein Server (Was du genannt middle server) 
(1) | | (2) 
/------------------/\-----------------\ 
| | 
Ihre VNCServer <----------------------------> client 
(5) (3) 

(1) Dem Ersten verbindet, um den Haupt-server. So, dann den main server habe den VNCServer seine IP.

(2) Der client eine Verbindung zum main-server.

(3) Nun die wichtigsten server weiß, wo sich server und client. Dann sendet er an den client, wo der server ist. Dann stellt der client eine Verbindung zu der IP-erhielt er aus den main-server. Das ist natürlich die IP vom VNCServer.

(5) Der VNCServer läuft, ist der server zum akzeptieren der client.

Nun desktop-sharing starten können.

Ich denke, dies ist die situation, die Sie empfehlen können.

Natürlich schreiben Sie in Java ist die Ihnen.

Den ServerSocket erlaubt Ihnen zu hören, für die verbindungen auf einem bestimmten port. Wenn ein server-socket akzeptiert eine Verbindung, es spawnt ein anderer thread, und zieht die Verbindung zu einem anderen port, so dass der ursprüngliche port kann immer noch hören, für zusätzliche Anschlüsse.

Der client initiiert die Verbindung auf dem port bekannt. Dann, in der Regel, der client sendet einige Anfrage, und der server antwortet. Dies wird wiederholt, bis die Kommunikation abgeschlossen ist. Dies ist die einfache client/server-Ansatz, der das web nutzt.

Wenn Sie nicht brauchen, dieser Mechanismus, und die Anfragen kommen entweder von Steckdose zu jeder Zeit, dann die Umsetzung der reader-und writer-threads, so, wie Sie scheint angemessen zu sein.

Intern, Sie verwenden noch warten, Mechanismen, so sollten Sie nicht zu viel zu sehen, die CPU-Auslastung während Sie warten, bis Daten ankommen.

Ich denke, dass Sie noch brauchen, ein Ende zu einem server-socket, weil ich nicht denke, es ist möglich, ein client-socket eine Verbindung akzeptiert. ClientSocket impliziert, TCP, die für die eine Verbindung erforderlich. Wenn Sie verwendet DatagramSocket-Objekt, was bedeutet, UDP, Sie hätten client-zu-client-Kommunikation, ohne eine Verbindung.

Einen socket (in networking-Bedingungen) besteht aus 2 Endpunkten (client und server app) und 2 streams. Der output-stream des Kunden wird der input-stream des Servers und Umgekehrt.

Nun versuchen Sie sich vorzustellen, was passiert, wenn ein thread schreibt eine Menge von Daten in einen stream, während niemand liest... Es gibt Puffer, stimmt, aber Sie sind nicht unbegrenzt und Sie können in der Größe variieren. Am Ende Ihres Schreibens thread auf die Beschränkung des Puffers und wird blockiert, bis jemand befreit den Puffer.

Having said,, Sie sollte jetzt bewusst sein, dass dies brauchen mindestens zwei verschiedenen threads pro Stream: einer, der schreibt, und einer, der liest die geschriebenen bytes.

Wenn Ihr Protokoll-Anforderung-Antwort-Stil, Sie könnten stick mit 2 threads pro sockel, aber nicht weniger.

Könnten Sie versuchen, zu ersetzen, die dem networking-Teil der Anwendung. Erstellen Sie einfach eine abstrakte Schnittstelle, wo Sie können ausblenden, das ganze networking-Teil, wie:

interface MyCommunicator{
  public void send(MyObject object);
  public void addReader(MyReader reader);
}

interface MyReader{ //See Observer Pattern for more details
  public void received(MyObject object);
}

Diese Weise können Sie leicht entfernen Sie das gesamte Netzwerk (einschließlich en- & Entschlüsselung der Objekte, etc.) und minimieren threading.

Wenn Sie möchten, dass die Daten Binär, Sie könnte verwenden Rohre statt oder der Umsetzung Ihrer eigenen streams zu verhindern threading.
Der Geschäfts-oder Verarbeitung von Logik, sollten Sie nicht wissen, über sockets, streams sind low-level genug und vielleicht zu viel.

Aber so oder so: Threading ist nicht schlecht, solange Sie nicht übernutzung es.

Warum brauchen wir ein middle server? Wenn Sie nur wollen, zu entlarven VNCServer. Warum nicht versuchen, eine Architektur, die wie folgt

VNCServer(S) <-> (C)MyApp(S) <-> (C) User

(S) represents a server socket
(C) represents a client socket

In diesem Fall die Anwendung fungiert sowohl als client (für den Ersten) und als server(für den Benutzer). So haben Sie zu implementieren, sowohl client-als auch server-sockets in der Anwendung und leitet die Daten.

Edit: Zur Kommunikation mit der Ersten Anwendung muss wissen, die IP-Adresse des VNCServer. Benutzer werden nur die Kommunikation mit der Anwendung und muss nur wissen Anwendung die IP-Adresse. Benutzer braucht nicht VNCServer ip-Adresse.

Allgemein gesprochen, eine client-TCP-socket hat zwei enden (lokale und "remote") und einer server-TCP-socket hat ein Ende (denn es wartet auf einen client, um eine Verbindung herzustellen). Wenn ein client verbindet sich zum server, der server intern erzeugt einen client-socket zu bilden, angeschlossen, paar client-sockets, die für die Kommunikation Kanal; es ist ein paar, weil jeder Steckdose, Blick auf den Kanal von einem Ende. Dies ist, Wie TCP Funktioniert (auf hohem Niveau).

Kann man nicht haben zwei client-sockets eine Verbindung zu jedem anderen in TCP, als die low-level-Verbindung-Protokoll funktioniert nicht so. (Sie können eine verbundene paar von sockets erstellt, die Art und Weise in Unix, aber es ist nicht ausgesetzt, die in Java-und Sie sind nicht-TCP-sockets.) Was Sie kann tun ist, schließen Sie den server socket sobald du akzeptiert hast eine Verbindung; für einfache Fälle mag das gut genug sein.

UDP-sockets sind unterschiedlich, natürlich, aber Sie arbeiten mit Datagrammen und nicht Ströme. Das ist ein ganz anderes Modell der Kommunikation.

Den klassischen Java-Ansatz zur Verbindung basierte socket-Kommunikation ist die Einrichtung einer ServerSocket auf eine bekannte IP und port und blockieren Sie es annehmen, Anruf, der (nach einem erfolgreichen Verbindungsversuch) liefert eine neue Buchse mit einer Implementierung bestimmt-port (anders als die ServerSocket's port). In der Regel die zurückgegebenen socket wird an einen handler implementieren Runnable. Handler sind vorübergehend im Zusammenhang mit einer bestimmten Verbindung. Handler können wiederverwendet werden und sind im Zusammenhang mit einem bestimmten Thema in der Regel für die Lebensdauer der Verbindung. Die Blockierung der Natur der klassischen Java-socket-E /a ermöglicht den Anschluss von zwei Steckdosen diente im gleichen thread sehr schwierig.

Aber es ist möglich und nicht ungewöhnlich, zu verarbeiten, sowohl input-und output-streams eines Sockets auf dem gleichen thread und unterstützen eine einzelne Verbindung zu einer Zeit ermöglicht, die Runnable Anforderung fallen gelassen werden, d.h. es wird kein zusätzlicher thread benötigt wird, für die handler und die ServerSocket accept rufen Sie zurückgestellt wird, bis die aktuelle Verbindung geschlossen.

In der Tat, wenn Sie NIO Sie leicht umgehen kann viele verbindungen gleichzeitig auf der gleichen thread mit dem Selektor-Mechanismus. Dies ist eine der wichtigsten Funktionen von NIO, non-blocking I/O zu entkoppeln threads von verbindungen (ermöglicht die sehr hohe Anzahl von verbindungen behandelt werden, die von kleinen thread-pools).

Soweit die Topologie des Systems, das tut mir Leid, ich bin noch nicht klar, was Sie nach sind, aber es klingt wie ein job für einen NAT service oder irgendeine Art von proxy überbrückung der öffentlichen IP auf die private IP.