Connecter deux sockets client

Tout d'abord, ne l'appelez pas accepté client (côté serveur) son support un Client Socket. C'est très déroutant.

Disons comment avoir deux socket client obtenir reliés entre eux sans l'aide d'un intermédiaire ServerSocket?

Ce qui est impossible. Vous avez toujours à faire côté serveur, ce qui peut accepter des clients. Maintenant, la question est: de quel côté de la connexion doit être le côté serveur?

Choses que vous devez penser, par la présente décision:

• Un serveur doit avoir une IP publique statique.
• Un serveur, ce qui est après un routeur connecté, a à faire "port forwarding". (Voir UPnP)
• Un client de a à savoir quelle machine il doit se connecter (IP publique)

Moyen serveur

Je ne vois pas ce que vous voulez faire avec ce troisième serveur. Peut-être la tenue de la VNCServer IP publique?
*Elister* a écrit, vous voulez faire un pont entre le client et le VNCServer. Je ne vois pas l'avantage.

Pourquoi ne pas faire immédiatement une connexion à la VNCServer?

Mais si vous le voulez vraiment, vous pouvez faire ce genre de situation:

 
/VNCServer (Serveur en cours d'Exécution) <---. 
| | 
LAN -| se Connecte à VNCServer 
| | 
\ Monappli (Serveur Exécutant --> Accepte à partir du Milieu du Serveur) <------. 
| 
(Par l'intermédiaire d'un routeur) 
| 
Moyen de serveur (Serveur Exécutant --> Accepte client) ---> se Connecte à Votre Application 
^ 
| 
(Par l'intermédiaire d'un routeur) 
| 
Client --> se Connecte à Moyen Serveur --° 

Et c'est à quoi il ressemble sans le troisième serveur (Ce que je vous recommande):

 
/VNCServer (Serveur en cours d'Exécution) <---. 
| | 
LAN -| se Connecte à VNCServer 
| | 
\ Monappli (Serveur Exécutant --> Accepte les Clients) <------. 
| 
(Par l'intermédiaire d'un routeur) 
| 
Client --> se Connecte à MyApp --------------------------° 

EDIT:

Je crois que j'ai maintenant:

Nous avons de visualiser votre situation comme ceci:

 De votre Serveur Principal (Ce que vous avez appelé milieu serveur) 
(1) | | (2) 
/------------------/\-----------------\ 
| | 
Votre VNCServer <----------------------------> Le client 
(5) (3) 

(1) La VNCServer se connecte au serveur principal. De la sorte, alors le serveur principal a obtenu le VNCServer son adresse IP.

(2) Le client se connecte au serveur principal.

(3) Maintenant le serveur principal sait où le serveur et le client sont. Puis il envoie au client sur le serveur. Ensuite, le client va se connecter à l'IP, il a reçu du serveur principal. C'est bien sûr l'adresse IP du VNCServer.

(5) La VNCServer est en cours d'exécution du serveur est d'accepter le client.

Maintenant de partage de bureau peut commencer.

Je pense que c'est le plus recommander situation que vous pouvez avoir.

Bien sûr écrit en Java est à vous.

Le ServerSocket vous permet d'écouter les connexions sur un port particulier. Lorsqu'un socket serveur accepte la connexion, il donne naissance à un autre thread, et déplace la connexion à un autre port, de sorte que le port d'origine peut toujours écouter les connexions supplémentaires.

Le client initie la connexion sur le port connus. Ensuite, généralement, le client devra envoyer une demande, et le serveur va répondre. Cette fonction permet de répéter jusqu'à ce que la communication est terminée. C'est la simple approche client/serveur que le site utilise des.

Si vous n'avez pas besoin de ce mécanisme, et les demandes peuvent provenir soit d'une prise à tout moment, la mise en œuvre, le lecteur et l'écrivain threads de la façon dont vous avez semble le plus approprié.

En interne, ils utilisent toujours attendre mécanismes, de sorte que vous ne devriez pas voir beaucoup d'utilisation de l'UC pendant qu'ils attendent pour les données arrivent.

Je pense que vous avez encore besoin d'une fin pour être un serveur de socket parce que je ne pense pas que c'est possible d'avoir un socket client d'accepter une connexion. ClientSocket implique TCP, ce qui nécessite une connexion. Si vous avez utilisé DatagramSocket, ce qui implique UDP, vous pourriez avoir de client à client de communication, sans connexion.

Un socket (en termes de réseautage) se compose de 2 points de terminaison (le client et Le serveur d'application) et 2 streams. Le flux de sortie du client est le flux d'entrée du serveur et vice-versa.

Maintenant, essayez d'imaginer ce qui se passe si un thread écrit un grand nombre de données en un flux alors que personne ne lit... Il y a des tampons, c'est vrai, mais ils ne sont pas illimitées, et ils peuvent varier en taille. À la fin de votre thread d'écriture, le succès à la limite de la zone tampon et bloquera jusqu'à ce que quelqu'un libère la mémoire tampon.

Cela dit, vous devriez être conscient que cela aura besoin d'au moins deux threads différents par Flux: celui qui écrit et celui qui lit les écrits octets.

Si votre protocole de requête-réponse, de style, vous pourriez rester avec 2 threads par socket, mais pas moins.

Vous pouvez essayer de remplacer le réseau de votre application. Il suffit de créer une interface abstraite où vous pouvez masquer l'ensemble du réseau, comme:

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);
}

Cette façon, vous pouvez facilement supprimer l'ensemble du réseau (y compris l'en- & décodage de vos objets, etc) et de minimiser le filetage.

Si vous voulez que les données binaires, vous pouvez utiliser des tubes à la place ou mettre en place votre propre flux pour empêcher le filetage.
L'entreprise ou de la logique de traitement ne devraient pas connaître les sockets, les ruisseaux sont de bas niveau assez et peut-être de trop.

Mais de toute façon: le Filetage n'est pas mauvais, tant que vous n'en abusez pas.

Pourquoi avons-nous besoin d'un moyen de serveur? Si vous voulez juste pour exposer VNCServer. Pourquoi ne pas essayer une architecture comme suit

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

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

Dans ce cas MyApp agit à la fois comme un client (pour VNCServer) et un serveur(pour l'Utilisateur). Ainsi, vous aurez à mettre en œuvre à la fois le client et le serveur de sockets dans MyApp et transmet les données.

Edit: Pour communiquer avec VNCServer, MyApp besoins de connaître l'adresse IP de l'VNCServer. L'utilisateur ne seront communiquer avec MyApp et a seulement besoin de savoir MyApp l'Adresse IP. L'utilisateur n'a pas besoin de VNCServer l'adresse ip.

En règle générale, un client TCP socket a deux extrémités (locale et “à distance”) et un serveur de socket TCP a une fin (car il est en attente pour un client de se connecter). Lorsqu'un client se connecte au serveur, le serveur en interne génère un client socket pour former connecté paire de sockets client qui représentent le canal de communication; c'est une paire parce que chaque prise de vues de la chaîne à partir d'une extrémité. C'est de cette Façon TCP Fonctionne (à haut niveau).

Vous ne pouvez pas avoir deux sockets client se connecter les uns aux autres dans TCP, comme le faible niveau de protocole de connexion ne fonctionne pas de cette façon. (Vous pouvez avoir un couple de prises créé de cette façon dans Unix, mais il n'est pas exposé en Java, et ils ne sont pas les sockets TCP.) Ce que vous peut faire est de fermer la socket du serveur une fois que vous avez accepté une connexion; pour les cas simples, qui pourrait être assez bon.

Les sockets UDP sont différents, bien sûr, mais ils travaillent avec des datagrammes et non de flux. C'est un modèle très différent de la communication.

Le classique Java approche de connexion à base de socket de communication est de mettre en place un ServerSocket sur une IP et le port et sur le bloc, c'est accepter l'appel, qui (à la suite d'une tentative de connexion réussie) retourne une nouvelle Socket avec une mise en œuvre déterminée de port (différente de la ServerSocket's de port). Généralement, le retour de socket est transmis à un gestionnaire de mise en œuvre Praticable. Les gestionnaires sont temporairement associée à un lien particulier. Les gestionnaires peuvent être réutilisés et sont associés à un thread particulier en général pour la durée de vie de la connexion. Le blocage de la nature de classique Java socket IO rend la connexion de deux sockets servi par le même thread très difficile.

Toutefois, il est possible, et pas rare, à la fois d'entrée et de sortie des flux d'un socket sur le même thread et le soutien d'une seule connexion à la fois permet à la Praticable exigence d'être abandonné, c'est à dire pas de thread supplémentaire est nécessaire pour le gestionnaire et le ServerSocket accepter appel est reportée jusqu'à ce que la connexion en cours est fermé.

En fait, si vous utilisez NIO, vous pouvez facilement gérer plusieurs connexions simultanément sur le même thread à l'aide du Sélecteur mécanisme. C'est l'une des caractéristiques les plus importantes de NIO, non-blocage I/O à découpler les fils de connexions (permettant à un grand nombre de connexions à être manipulés par de petits pools de threads).

Autant que la topologie de votre système, je suis désolé, je ne suis pas encore clair ce que vous êtes après, mais ça sonne comme un travail pour un NAT service ou une sorte de proxy combler l'adresse IP publique à l'adresse IP privée.