Loses Grid aufbauen

renwal

Aktives Mitglied
Hallo!

Vielleicht ist das ein etwas übertriebenes Projekt, aber ich möchte mir für extrem rechen-, datentransfer-, etc. -lastige Aufgaben eine Art Grid programmieren, das allerdings so lose aufgebaut ist, dass jederzeit Rechner hinzugefügt oder entfernt werden können (Entfernen natürlich nur, während der Rechner im Leerlauf ist).
Bisher habe ich erste Versuche mit DatagramSockets gewagt, über die ich dann per Multicast Daten an die angeschlossenen PCs verschickt habe. Ich bin da aber sehr schnell an die Grenzen gelangt, da ich nicht gleichzeitig über den gleichen Port senden und empfangen kann bzw. auch, wenn ich mehrere Ports benutze, den gleichen Rechner nicht mehrfach in die entsprechende Gruppe (213.0.0.1) eintragen kann.

Wie ich mir die Funktionsweise vorstelle:
Auf jedem beliebigen Rechner, der sich im gleichen Netzwerk wie das Grid befindet, notfalls von außen auch per VPN, lässt sich eine Steuersoftware bzw. Eingabemaske starten, die per Multicast die "Aufforderung" zum Rechnen verschickt. Daraufhin erhält ein Rechner, der zuerst reagierende, die "Rechenaufgabe" und teilt dann entsprechend der aktuellen Last der einzelnen Teile des Netzwerkes die Aufgabe auf und vergibt die Teile an die PCs.
Ist eine Teilaufgabe fertig, geht die Meldung zurück an den für diese Aufgabe gewählten "Master"-PC. Ist die Aufgabe gelöst, wird das Ergebnis zurück an den Rechner übertragen, auf dem die Eingabemaske läuft.
Wichtig wäre es, so selten wie möglich große Ergebnissätze übers Netzwerk zu übertragen, um dadurch nicht das gesamte Grid auszubremsen.
Laufen soll dieses Grid übrigens nicht auf irgendwelchen Hochleistungsrechnern, sondern ganz einfach auf den eingeschalteten aber gerade nicht benutzten Rechnern bei uns.

Ich weiß, das ist vllt. etwas "größenwahnsinnig" :D, aber denkt ihr, mir ist dabei (noch :D) zu helfen?
 

irgendjemand

Top Contributor
mal davon abgesehen das 213.0.0.0/8 der falsche bereich für multicast ist wäre hier wohl ne VPN-lösung am besten

multicast ist im bereich 224.0.0.0 bis 239.255.255.255 -> Multicast ? Wikipedia
wobei es auch hier einschränkungen gibt ...
laut wiki sollten folgenden bereich wegen sonder-aufgaben gemieden werden

224.0.0.0 - 224.255.255.255 -> reserviert für routing-protokolle
239.0.0.0 - 239.255.255.255 -> reserviert für scoping
233.0.0.0 - 233.255.255.255 -> reserviert für GLOP

daraus folgt das man für eigene multicast-"netze" folgende bereich bevorzugen sollte

225.0.0.0 - 232.255.255.255 und 234.0.0.0 bis 238.0.0.0

ggf mal bei IANA nachlesen ob es mitlerweile weitere einschränkungen gibt

ganz spontan *wobei ich nicht weis ob das auf deinen fall anwendbar wäre* würde mir LogMeIn Hamach2 einfallen ... zumindest für den privatgebraucht kostenlos ...
soweit ich weis unterstützt dies aber kein multicast ...
also bräuchtest du einen master-server bei dem sich alle clienten und server anmelden und so die verbindung zu ein ander aufgebaut werden kann ...
 

renwal

Aktives Mitglied
Gut, dann wäre das mit dem VPN erstmal geklärt. Brauche ich dann aber nur für einen Zugriff von außen, oder?

Mit dem Master-Server ist das aber blöd, da ja immer andere Rechner laufen, d.h. ein dauerhafter Master ist nicht realisierbar. Da muss irgendeine andere Lösung her.
Wie kann ich denn das Problem mit dem Senden/Empfangen angehen, sodass das über eine Gruppe abgewickelt werden kann? Hat da jemand eine Idee?

PS: Ich hatte die Gruppen-IP falsch in Erinnerung. Im Quellcode steht 230.0.0.1.

LG René
 

ThreadPool

Bekanntes Mitglied
Gut, dann wäre das mit dem VPN erstmal geklärt. Brauche ich dann aber nur für einen Zugriff von außen, oder?

Mit dem Master-Server ist das aber blöd, da ja immer andere Rechner laufen, d.h. ein dauerhafter Master ist nicht realisierbar. Da muss irgendeine andere Lösung her.
[...]

Weshalb würde man einen dauerhaften Master benötigen? "Normalerweise" läuft das mit einem Master doch ungefähr so dass es einen Master pro Berechnung bzw. Task gibt der die Verteilung von Tasks an die Arbeitsmaschinen vornimmt sowie die Arbeitsmaschinen über den Ort von Eingabedaten oder Zwischenergebnissen informiert. Sobald man das Ergebnis des Tasks hat benötigt man den Master auch nicht mehr. Des Weiteren führt der Master eine Art Fehlerbehandlung durch indem er Tasks von abgestürzten Maschinen neu verteilt, überprüft ob noch alle Arbeitsrechner da sind und wenn ein Task z.B. extrem lange läuft er den selben Task auf einer anderen Maschine startet, weil vll. mit dem Langläufer was nicht stimmt.

Du kannst auch mehrere Master auf der selben Maschine starten, es muss eben gewährleistet sein das die nicht versuchen über die selben Ports kommunizieren. Das Alles macht natürlich auch nur Sinn wenn die Aufgabe überhaupt sinnvoll parallelisierbar ist.
 

renwal

Aktives Mitglied
Weshalb würde man einen dauerhaften Master benötigen? "Normalerweise" läuft das mit einem Master doch ungefähr so dass es einen Master pro Berechnung bzw. Task gibt der die Verteilung von Tasks an die Arbeitsmaschinen vornimmt sowie die Arbeitsmaschinen über den Ort von Eingabedaten oder Zwischenergebnissen informiert.
Es ging bei dem Master auch nur um einen VPN-Master, der die Verbindung der Eingabemaske von außen entgegennimmt. Sonst wollte ich das eben so machen, dass der Master für eine einzelneBerechnung festgelegt wird.

es muss eben gewährleistet sein das die nicht versuchen über die selben Ports kommunizieren.
Das Problem scheint auch nicht an den Ports zu liegen, sondern an der Gruppe. Beim Start von Server und Client (hab mir einfach zum Ausprobieren einen Multicast-Server und -Client programmiert, wobei der Server immer "Hello" sendet) auf einem Computer erhalte ich eine Fehlermeldung. Wenn ich Zeit habe, versuche ich das nochmal und lade mal die Fehlermeldung hoch.

LG René
 

irgendjemand

Top Contributor
Weshalb würde man einen dauerhaften Master benötigen? "Normalerweise" läuft das mit einem Master doch ungefähr so dass es einen Master pro Berechnung bzw. Task gibt der die Verteilung von Tasks an die Arbeitsmaschinen vornimmt sowie die Arbeitsmaschinen über den Ort von Eingabedaten oder Zwischenergebnissen informiert. Sobald man das Ergebnis des Tasks hat benötigt man den Master auch nicht mehr. Des Weiteren führt der Master eine Art Fehlerbehandlung durch indem er Tasks von abgestürzten Maschinen neu verteilt, überprüft ob noch alle Arbeitsrechner da sind und wenn ein Task z.B. extrem lange läuft er den selben Task auf einer anderen Maschine startet, weil vll. mit dem Langläufer was nicht stimmt.

Du kannst auch mehrere Master auf der selben Maschine starten, es muss eben gewährleistet sein das die nicht versuchen über die selben Ports kommunizieren. Das Alles macht natürlich auch nur Sinn wenn die Aufgabe überhaupt sinnvoll parallelisierbar ist.

hmm ... da hast du wohl das problem nicht ganz erfasst ...

es geht darum das das MultiCast aus irgendeinem grund nicht zuverlässig arbeitet und sich desshalb controller und worker gegenseitig nicht finden und/oder keine daten austauschen können ...
dieses problem kann man umgehen in dem man einen "master-server" hat an den sich ALLE anfragen richten .. sowohl von allen controllern um die einzelnen worker zu finden ... als auch von den workern um sich an- und abzumelden ...

@TO : warum ist das nicht mögich ?

ansonsten ging es auch darum das halt auch von außen der zugriff möglich sein soll ... und da ist nun mal die einfachste variante ein VPN ...
nun könnte man auch den master-server auf dem das vpn läuft gleichzeitig zu dem server machen an den alle anfragen gehen ...
ob man sich nun den aufwand macht und die server-software so schreibt das man prüft ob die anfrage aus dem intranet kam oder aus dem vpn .. und dann entsprechend die adressen zugewiesen werden ... oder ob man alle rechner ... gleich ob im intranet oder nicht komplett ins vpn hängt und dann nur über dessen adressen kommuniziert ...
hat den vorteil das controller "von außen" transparent eingefügt werden können ...
den nachteil : alles was im intranet ist hat im logischen sinn eine redundante anbindung ...


ist also etwas komplexer ... hab da halt auch so selbst keine bessere lösung parat als einen zentralen master-server ... aber der scheidet ja aus *warum eigentlich ?*
 

bERt0r

Top Contributor
Also ich würd mir einfach den Source eines Gnutella Clients ziehen (gibts auch in Java) und mir dort den Netzwerkaufbau ansehen. Klingt nämlich so, als wäre das die Art von "losem Grid" die du haben willst. Man muss ja das Rad nicht neu erfinden...
 

irgendjemand

Top Contributor
hmm ... ob P2P hier ne gute grundlage ist ? ich mein : arbeitet vorwiegend auf UDP um sich durch Hole Punching auch mit "firewalled" clients verbinden zu können ...
 

bERt0r

Top Contributor
Alos wenn du hier von multicast sprichst hast du doch ohnehin udp und um holepunching gehts hier doch gar nicht. Der TO will ein Netzwerk mit ein paar Master-Nodes, welche einer Menge ans Slave-Nodes Aufgaben zuweisen. Das klingt ähnlich wie die Hub/Leaf Architektur von gnutella.
 

irgendjemand

Top Contributor
auf die gefahr mich zu wiederholen : diese scheinbar einfache aufgabe lässt sich laut TO bei ihm scheinbar nicht umsetzen ... zu mal es auch möglich sein soll von "außen" diesen "dienst" zu nutzen ... was nun mal am einfachsten mit nem VPN geht ...

und auch wenn man nur multicasting nutzt um irgendwen im netz zu finden und den rest via TCP abwickelt scheitert es ja trotzdem irgendwo laut aussage von TO
 

renwal

Aktives Mitglied
hmm ... da hast du wohl das problem nicht ganz erfasst ...

es geht darum das das MultiCast aus irgendeinem grund nicht zuverlässig arbeitet und sich desshalb controller und worker gegenseitig nicht finden und/oder keine daten austauschen können ...
dieses problem kann man umgehen in dem man einen "master-server" hat an den sich ALLE anfragen richten .. sowohl von allen controllern um die einzelnen worker zu finden ... als auch von den workern um sich an- und abzumelden ...

@TO : warum ist das nicht mögich ?

Dazu habe ich doch schonmal etwas geschrieben:

renwal hat gesagt.:
Mit dem Master-Server ist das aber blöd, da ja immer andere Rechner laufen, d.h. ein dauerhafter Master ist nicht realisierbar. Da muss irgendeine andere Lösung her.

Ich habe ja keine speziellen Rechner, die das Rechennetzwerk bilden, sondern möchte das Grid auf den momentan nicht benutzen Computern in einem Netzwerk beliebiger Größe aufbauen. Es steht also kein Master-Server zur Verfügung, der dauerhaft läuft.
Jetzt könnte man natürlich einfach einem Rechner den Master-Status zuweisen. Wird aber dann der Rechner wieder benutzt (wodurch sich der Rechner vom Grid abmeldet) oder heruntergefahren, gäbe es keinen Master mehr. Läuft jetzt eine Anfrage, verlieren alle beteiligten Rechner die Verbindung und die Berechnung bricht ab. Das sollte aber auf jeden Fall vermieden werden.

________________________________

irgendjemand hat gesagt.:
und auch wenn man nur multicasting nutzt um irgendwen im netz zu finden und den rest via TCP abwickelt scheitert es ja trotzdem irgendwo laut aussage von TO

Naja, es scheitert halt am Versuch, vom gleichen Rechner sowohl Multicasts zu senden als auch zu empfangen, denn dafür muss ja sowohl ein Server als auch ein Client eingerichtet sein.

PS: Fehler gefunden. Die Verbindung scheiterte, weil ich doch den gleichen Port verwendet hatte. Ich hab beim Umschreiben des Codes nicht gemerkt, dass ich den Server-Port im Client übernommen habe :oops:. Die Fehlermeldung zeigte dann zwar einen Fehler bei der Gruppenzuweisung, aber der lag dann wohl an diesem Problem. Aber die Frage mit dem Master bleibt ja weiterhin.
 

irgendjemand

Top Contributor
da muss ich dir aber wiedersprechen ...

du kannst sehrwohl auf EINEM rechner gleichzeitig einen multicast-"server" laufen lassen als auch einen multicast-"client" ...

denn nur der server wird dauerhaft auf den port gebunden ... daraus ergibt sicher aber NICHT das problem das du gleichzeitig vom selben rechner ein unicast-paket über den selben port schicken kannst ...

kann auch sein das du die implementierung von multicast anders gelöst und den client so implementiert hast das dieser ebenfalls auf den port gebunden wird ... ist aber meiner ansicht nach nicht wirklich die sinnvolle lösung ...

wenn im netz mal so rumsucht findet man meist das beispiel das der "server" dauerhaft auf pakete wartet die via multicast vom client geschickt werden ... dabei wird im client jedoch kein fester source-port definiert sondern dieser automatisch vom system vergeben ...
erhält nun der server ein paket vom client beantwortet er dieses direkt in dem er sich über die methoden die source-ip und den source-port holt ... anstatt die antwort wieder über multicast rauszufeuern ... weil dafür müsste der client auch eine art "empfangsserver" sein ... was dann natürlich nur mit unterschiedlichen ports funktioniert ...

klar gibt es das auch andersrum das der client auf pakete wartet die vom server regelmäßig gesendet werden und der client beantwortet diese dann dierekt ... das kann man drehen und wenden wie man will ... aber sowohl anfrage als auch ergenis beide über multicast zu senden ist keine gute idee ...

wie oben erwähnt : am besten implementierst du den server so das er halt dauerhaft auf pakete wartet ...
wenn nun ein client ein "DISCOVER" pakete über multicast sendet beantworten die server die dieses empfangen haben mit einem "OFFER" direkt ... so das der client dann bei erhalt des paketes die source-ip ermitteln kann ...
nun hat der client eine liste aller möglicher server und deren ips ...
den rest erledigt man jetzt über TCP da man ja nun das ziel kennt ... und es so dierekt adressieren kann ...
 

renwal

Aktives Mitglied
da muss ich dir aber wiedersprechen ...

du kannst sehrwohl auf EINEM rechner gleichzeitig einen multicast-"server" laufen lassen als auch einen multicast-"client" ...

denn nur der server wird dauerhaft auf den port gebunden ... daraus ergibt sicher aber NICHT das problem das du gleichzeitig vom selben rechner ein unicast-paket über den selben port schicken kannst ...

kann auch sein das du die implementierung von multicast anders gelöst und den client so implementiert hast das dieser ebenfalls auf den port gebunden wird ... ist aber meiner ansicht nach nicht wirklich die sinnvolle lösung ...

Ich hätte es vielleicht als EDIT und nicht als PS schreiben sollen, aber ich hab doch gesagt, dass mir genau das auch aufgefallen ist, ich es korrigiert habe und es so funktioniert.
Den Server und Client, die ich rein für die Kenntnis des Funktionsprinzips programmiert habe, habe ich übrigens aus den Oracle Docs (Broadcasting to Multiple Recipients).

aber sowohl anfrage als auch ergenis beide über multicast zu senden ist keine gute idee ...

Das hatte ich auch nie vor. Mein Plan ist folgender:

  • Eine Anfrage kommt über das Netzwerk per Multicast.
  • Der zuerst reagierende Rechner baut eine Verbindung per Socket auf.
  • Dieser Rechner erhält die Anfragedaten und wird damit temporär zum Master.
  • Der Rechner sendet eine Anfrage zur Identifikation per Multicast.
  • Alle anderen Rechner reagieren darauf mit einem Antwortpaket zurück an diesen Rechner.
  • Anhand der IPs dieser Pakete baut der Rechner nacheinander Verbindungen zu all diesen Rechnern auf und erfragt die aktuellen Leistungsparameter.
  • Der Rechner bereitet die Parallelisierung der Anfrage entsprechend der Leistungsdaten der Teilnehmer vor.
  • Es werden Verbindungen zu allen teilnehmenden Rechnern aufgebaut und die Aufgaben verteilt.
  • Ist eine Teilaufgabe fertig, so teilt der ausführende Rechner das dem Master mit.
  • Der Master gibt Befehle zur weiteren Behandlung dieser Teilaufgabe (zurück an den Master / weiterleiten an Rechner xy).
  • Sind alle Ergebnisse da, so gibt der Master das Gesamtergebnis an den anfragenden Rechner zurück.
  • Der Master gibt den Master-Status ab.

Bei den Rückmeldungen zum Master sehe ich jedoch aktuell das Problem, dass die Verbindungsversuche kollidieren könnten. Kann man das irgendwie verhindern? (So, dass der Verbindungsversuch nicht andauernd wiederholt werden muss und das das Netzwerk ausbremst.) Kann man mehrere Verbindungen gleichzeitig annehmen, ohne das alle diese Ports den anfragenden Rechnern bekannt sind?
 

irgendjemand

Top Contributor
klingt an sich eigentlich ganz gut der ablauf ... verstehe aber deine letzte frage in dem zusammenhang nicht ...

trennst du die verbindungen nach übergabe der daten oder hältst du diese offen ?
wenn du sie schließt : wer baut dann zu wem wann die verbindung neu auf um die ergebnisse abzuliefern ?

auch ist "der zuerst reagierende rechner baut eine verbindung auf" schon alleine beim lesen ziemlich schräg ...
IMO sollten alle "potentiellen master" erstmal das erste vom client kommende multicast mit der meldung "bereit" bestätigen ...
wie sich nun der client für einen bestimmten master-server entscheidet oder ob schon der client teilweise versucht alles zu parallelisieren in dem er verbindung mit mehreren master-servern aufbaut ist erstmal nebensächlich ...

und das letzte verstehe ich garnicht : rechner gibt master-status ab : an wen ? woher ? gegenüber welcher kontroll-instanz ?

woher bezieht denn ein potentieller server den status "MASTER" ... und gegenüber WEM ist dieser von bedeutung ? kann mir darauf keine antwort bilden


und zu mehreren verbindungen

Java:
while(true)
{
(new ClientHandleThread(ServerSocket.accept())).start();
}

einfach im server threads verwenden ... da musst du dir keine gedanken über irgendwelche ports machen ...
 

renwal

Aktives Mitglied
irgendjemand hat gesagt.:
trennst du die verbindungen nach übergabe der daten oder hältst du diese offen ?
wenn du sie schließt : wer baut dann zu wem wann die verbindung neu auf um die ergebnisse abzuliefern ?

Alle normalen Socket-Verbindungen werden nach der Datenübertragung wieder geschlossen. Einzig die Multicast-Verbindung bleibt bestehen (wenn man das Verbindung nennen kann). Reinitialisiet wird eine Verbindung immer von dem Rechner, der Daten zu übermitteln hat. Kann man die Verbindungen einfach offen lassen, ohne dass es zu Problemen kommt, wenn ein Rechner unerwartet ausfällt und damit die Verbindung abbricht?

auch ist "der zuerst reagierende rechner baut eine verbindung auf" schon alleine beim lesen ziemlich schräg ...
IMO sollten alle "potentiellen master" erstmal das erste vom client kommende multicast mit der meldung "bereit" bestätigen ...

Warum? Ist es nicht egal, ob der Client die Verzögerungen der "Bereit"-Meldungen misst und sich dann für den schnellsten Master entscheidet oder ob einfach alle potentiellen Master versuchen, eine Socket-Verbindung zum Client herzustellen und, nachdem der erste, sprich schnellste, Master die Verbindung aufgebaut hat, alle anderen Verbindungen durch "Port belegt" fehlschlagen?

und das letzte verstehe ich garnicht : rechner gibt master-status ab : an wen ? woher ? gegenüber welcher kontroll-instanz ?

woher bezieht denn ein potentieller server den status "MASTER" ... und gegenüber WEM ist dieser von bedeutung ? kann mir darauf keine antwort bilden

Gut, das war unglücklich formuliert, da hast du Recht. Ich wollte damit einfach nur ausdrücken, dass der Master nicht Master bleibt, sondern erstmal wieder in die Gruppe der potentiellen Master kommt und dann bei der nächsten Anfrage wieder ein neuer Master ausgewählt wird.

und zu mehreren verbindungen
Java:
while(true)
{
(new ClientHandleThread(ServerSocket.accept())).start();
}

einfach im server threads verwenden ... da musst du dir keine gedanken über irgendwelche ports machen ...

Das klingt für mich so, als ob unendlich viele Threads gestartet werden. Dann ist aber doch irgendwann Schluss, oder? Verstehe ich das falsch?
 

irgendjemand

Top Contributor
aua ... da fehlen dir aber einige netzwerkgrundlagen ...

1) warum öffnest du eine verbindung von nem master zu nem worker ... übergibst die daten ... und trennst dann die verbindung wieder ?
und dann versuchst du ... nach dem der worker fertig ist eine neue verbindung zum master aufzubauen ... die daten abzuliefern ... und wieder zu schließen ...
das ist BUMS ...
baue eine verbindung vom master zum worker auf ... übergib die daten ... und warte dann einfach am stream mit einer read-methode auf daten ... das ist die übliche vorgehens weise ...

*und nein ... multicast ist keine verbindung da UDP*

2) "schnellster master"
nein ... das ist eben NICHT egal ... weil sich der master auch garnicht zum client verbinden sollte sondern immer nur der client zum master ...
außerdem würden die anderen master eben KEIN "port belegt" bekommen wenn der client einen server aufmacht ... und dann mit accept verbindungen annimmt ...
es würde höchstens irgendwann zum timeout kommen wenn der "client" halt nur einmal ServerSocket.accept() called ... bin mir da aber eher unsicher ...

wie ich bereits sagte : client senden multicast und erfragt damit welche master überhaupt zur verfügung stehen ... und auf dieses multicast reagieren die master mit einem direkten pakete das dem client sagt : "hier ich bin bereit" ...
WIE sich nun der client für einen master entscheidet kannst du machen wie du willst ... wobei das mit dem "zeiten der pakete messen" nicht so sauber klingt da pakete die über mehrere switches müssen halt länger brauchen ... obwohl der master und dessen verfügbare worker vielleicht viel mehr resourcen haben als der master und dessen worker dessen paket zu erst ankommt ...
außerdem spielt es bei sowas auch eine rolle wie lange das multicast-pakete braucht um erstmal bei allen mastern anzukommen ...

3) ja gut ... das mit dem release hab ich so halt nich verstanden ... danke für die erklärung ...

4) was heißt denn hier unendliche threads ... ?
das was ich gepostet habe war lediglich eine ganz einfache art und weise eines multi-threaded servers ... der halt mehrere client-verbindung gleichzeitig handlen kann ..
außerdem ist ServerSocket.accept() eine BLOCKIERENDE methode ... also bleibt der thread der dies ausführt dort so lange "hängen" bis sich ein neuen client verbindet ... -> DOC LESEN !


ich bezweifel langsam wirklich das du überhaupt das nötige wissen hast um das was du uns hier versuchst zu beschreiben überhaupt wirst umsetzen können ...


ich versuche es noch mal halbwegs einfach zu skizzieren ...


eine reihe von "master" servern mit daran "angeschlossenen" "worker" servern ...
einen client der nun eine aufgabe hat die von einem oder mehreren "workern" gelöst werden soll ...
client sendet multicast ins netz
die "master" reagieren auf dieses "discover" mit einem "offer" um dem client die bereitschafft zu signalisieren ...
der client sucht sich jetzt einen *oder sogar mehrere* "master" aus und verbindet sich ...
die aufgabe wird übermittelt ... verbindung bleibt offen um die ergebnisse wieder zurückzuschicken *TCP-verbindungen sind BI-direktional*
der master baut jetzt verbindungen zu den workern auf und verteilt die aufgabe ... auch diese verbindungen bleiben offen um die ergebnisse zurückzugeben ...
nun rechnen die worker an der aufgabe dran rum ...
ergebnisse werden an den master returned ... der setzt das in nen sinnvollen context ... die verbindungen zu den workern werden dann nach beendigung abgebaut ... wenn das ergebnis vorliegt sendet der master dieses an den client und trennt dann auch die verbindung ...
ggf muss der client nun die ergebnisse von mehreren mastern noch selbst zusammensetzen ...


und ich habe bis jetzt nicht mal im ansatz diesen ablauf bei dir gesehen ...

und da jetzt noch transparent mit VPN von außen was zu machen ... naja ... dürfte mit nem zentral-server im intranet gehen ... oder du packst alles ins VPN ... was aber nicht der sinn sein sollte ...
 

renwal

Aktives Mitglied
Gut, ich werde das Projekt wohl erst einmal ruhen lassen und Kenntnisse aufarbeiten :).

Danke für die bisherigen Antworten!
 

Ähnliche Java Themen


Oben