Socket String zu Socket

[Taramsis]

Hi Leute,

ich schicke Informationen über einen Socket per String durch ein Netwerk. Wie kann ich diesen wieder als Socket casten:

String socketBlub = split[0];
Socket blub = (cast) socketBlub; // geht nicht

Gibt es eine elegantere Methode als es zunächst als Object zu casten?

Danke im Voraus!

 

[SlaterB]

was soll man dazu sagen?
wenn in einem String "Lösung berechnen" steht, dann kann man das auch nicht zum Ergebnis int 42 casten..

was genau steht denn nun im Array, im String? etwas über den Socket oder die Information des Programms?
ist das noch bei Erzeugung des Arrays oder wurde schon erfolgreich übertragen?

warum sollte ein Array mit einer Information irgendwelche Rückschlüsse auf einen Socket enthalten?
wenn da eine Ip-Adresse + Port oder was auch immer drinsteht, dann extrahiere diese Informationen und erzeuge auf ganz normalen Wege
new Socket() usw.

 

[irgendjemand]

<T> object=(String)Socket;

von welchem typ *<T>* soll denn deiner meinung nach "object" sein ? ... du kannst keinen String zu einem Socket casten ... mal ganz davon abgesehen das du dann um damit zu arbeiten erstmal Socket.connect() callen müsstest ...

und was genau steht in deinem String ? ein IPORT - paar ? ... andere informationen ? oder nur die speicher-adresse ala Socket.toString() ?

ein bisschen mehr code dürfte es schon sein ... aber DAS da oben GEHT NICHT !!!

 

[Taramsis]

Hätte ich mir denken können!:rtfm:

1.) Es läuft wie folgt ab irgend ein Client schickt eine Nachricht an einen Server und verbindet sich mit diesem:

Socket skt = new Socket("IPdesServers", 4444);

2.) Der Server hört diesen Port ab und macht folgendes

ServerSocket serverSktClient = new ServerSocket(port);
while(alive){
    Socket skt = serverSktClient .accept();
....
}

3.) Nun schickt verteilt er diese Nachrichten an Unter-Server, dabei wollte ich Informationen über diesen Sochet mitschicken, um dann die Rückmeldung des Unter-Servers an diesen Client zurückzuschicken, weil es mehrere seinen können:

String outputline = serverSktClient + "; " + blablub + "\n" + inputLine;
PrintWriter out = new PrintWriter(new OutputStreamWriter(serverSktClient .getOutputStream()));

4.) Beim Auslesen der Rückmeldung beim Ober-Server wird dieser Socket mitgegeben

BufferedReader in = new BufferedReader(new InputStreamReader(skt.getInputStream()));
String split[] = Pattern.compile("; ").split(in.readLine());
String clientSocket= split[0]; // dass wäre mein Socket als String

Nunn möchte ich es halt als Socket haben! Kommt Ihr mit?

 

[SlaterB]

schau dir doch den String outputline an, da steht nichts sinnvolles drin,
die Speicheradresse eines anderen Java-Programms bringt dem Ober- (oder Unter-?)Server nichts,
du musst schon wie gesagt verständliche Informationen wie IP und Port versenden und immer korrekte neue Sockets erschaffen,

wobei vom Client wenig zu holen ist, die IP vielleicht, aber der Port der zustandegekommenen Verbindung bringt wenig,
solange serverSktClient läuft, kann der Server, der diese Verbindung zum Client hat, damit was anfangen,
andere können aber nicht (legal) in diese Verbindung eingreifen und wenn sie zu ist hat auch der Server nichts mehr davon,
er muss auf eine neue Meldung vom Client warten oder kann vielleicht eine Gegenverbindung aufbauen,
falls dieser Client auch selber irgendwo auf einen vereinbarten Port einen Server mit accept() laufen hat

 

[Taramsis]

Aso!

Dann - wie kann der Ober-Server die IP des Clients herausfinden?
Die Clients verschicken Ihre Nachrichten und hören dann mit über den gleichen Socket ab!
Sollte der Client diesen dann mitschicken als String?

Edit: mit skt.getInetAddress() oder skt..getLocalSocketAddress()!?

 

[SlaterB]

> mit skt.getInetAddress() oder skt..getLocalSocketAddress()!?
Rückgaben anschauen, alles ausprobieren

 

[Michael...]

Warum die Verteilung an "Unterserver"? Erläutere doch mal was Du vorhast.

Prinzipiell könnte der "Oberserver" die Verbindung durch den Client annehmen und ihm die Verbindungsdaten des "Unterservers" zu schicken, damit dieser sich mit diesem verbindet.
Ich würde aber diese Vorgehen grundsätzlich hinterfragen...

 

[irgendjemand]

das mit dem "client wartet auf verbindung vom server" solltet ihr mal ganz schnell wieder vergessen ...
denn spätestens an einem NAT-router mit firewall ist ende wenn kein port-forwarding eingerichtet wurde *alternative : udp-hole-punching*

was genau du da vorhast begreife ich auch nicht ...
wenn das ganze was mit load-balancing zu tun hat dann würde ich mir mal bei google entsprechendes material raussuchen ...
die wohl einfachste variante von load-balancing ist wohl das DNS-load-balancing ...
hat ziemlich einfache funktionsweise : du verbindest dich statt dierekt zu einer IP zu einem DNS-namen ... der DNS löst diese dann entsprechend seiner load-records in verschiedene IPs auf ...

aber einfach so einem anderen programm über toString eine speicher-adresse zuzuwerfen ... das bringt dir sehr wenig ...
auch ist es nicht *zumindest nicht ohne weiteres* möglich eine bestehende socket-verbindung so zu manipulieren das man diese "umleiten" kann ...

alles in allem sehr schwammig und ziemlich schwer zu verstehen was genau du da vorhast

 

[Taramsis]

Im Grunde genommen habe ich mehrere Clients, die Nachrichten in Stringform an ein Ober-Server schicken. Dieser Server leitet die Nachrichten (erstelle für jede Nachricht einen Thread) zunächst in eine FIFO danach werden diese Nachrichten an einen freien Unter-Server weitergeleitet der den Input in MATLAB (MATLAB ist nicht Thread safe deshalb diese Struktur berechnet und es an den Ober-Server zurück gibt. Jetzt muss der Ober-Server den Output an den entsprechenden Client senden.
Deshalb will ich jeder Nachricht die vom Ober-Server als Client-Input klassifiziert wurde den Client Socket bzw. IP hinzufügen, somit könnte es dem Thread übergeben und ausgeführt werden.

 

[Michael...]

Dieser Server leitet die Nachrichten (erstelle für jede Nachricht einen Thread) zunächst in eine FIFO danach werden diese Nachrichten an einen freien Unter-Server weitergeleitet der den Input in MATLAB (MATLAB ist nicht Thread safe deshalb diese Struktur berechnet und es an den Ober-Server zurück gibt.

Deswegen machen die "Unterserver" aber immer noch keinen Sinn, aber prinzipiell sollten diese die Antwort dann an den Oberserver senden, der diese an den Client weiterreicht.

Da aber die Anfragen sowieso nur sequentiell verarbeitet werden können: Warum speichert der Server diese nicht in einer Queue? Ein Thread holt sich die Aufträge aus der Queue und füttert damit Matlab die Ergebnisse übergibt er dann an den Server (evtl. auch in eine Queue) und dieser verteilt sie an die Clients.

 

[Taramsis]

Warum speichert der Server diese nicht in einer Queue? Ein Thread holt sich die Aufträge aus der Queue und füttert damit Matlab die Ergebnisse übergibt er dann an den Server (evtl. auch in eine Queue) und dieser verteilt sie an die Clients.

Das habe ich in der änlichen Form schon! Nun möchte ich mehrere MATLAB Umgebungen auf mehreren Unter-Server auslagern. Dadurch will ich die Performance erhöhen.

 

[Michael...]

Das habe ich in der änlichen Form schon! Nun möchte ich mehrere MATLAB Umgebungen auf mehreren Unter-Server auslagern. Dadurch will ich die Performance erhöhen.

Dann würde ich diese "Unterserver" als Clients der Serveranwendung gestalten und es ist dann auch nicht notwendig, dass die normalen Clients die Matlab Clients kennen und umgekehrt.
Wie findet denn aktuell die Kommunikation zwischen "Oberserver" und "Unterserver" statt?

 

[Taramsis]

Wie findet denn aktuell die Kommunikation zwischen "Oberserver" und "Unterserver" statt?

Ich bin noch nicht ganz fertig, aber der Oberserver soll für jeden ankommende Nachricht einen eigenen Thread starten. Hier wollte ich anhand eines mit geschickten Präfixes unterscheiden, ob es vom Client oder Unter-Server kommt. Wenn es vom Unter-Server kommt sollte die Nachricht an die mitgeschickten IP des Client geschickt werden. Wenn es vom Client kommt, wird es in ein Queue geschoben. Ein seperater Thread holt den nächsten Thread aus der Queue, falls ein Unter-Server frei ist.

 

[Michael...]

Aber warum wolltest Du dann das Socket an den "Unterserver" schicken? Der Berechnungsclient, muss doch vom "Auftragsclient" gar nichts wissen. Einzig der Server muss wissen von welchem Client er den Auftrag erhalten hat und an welchen Berechner er ihn weitergegeben hat.
Wie funktioniert es denn in der jetztigen Client Server Lösung bei der Server direkt Matlab ansteuert?

 

[irgendjemand]

aber so wirklich von TCP-kommunikation haltet ihr hier alle nichts oder ?

wo bitte ... wo bitte genau ist es so das problem die clients abzuarbeiten ?

ein ganz einfaches multi-client beispiel


SERVER
läuft in nem accept-loop

jedes mal wenn sich ein client connected macht der server einen neuen thread in dem die kommunikation abgehandelt wird ... für den server ist der fall erledigt und er wartet weiter auf den nächsten client


Con-Thread
in diesem läuft die kommunikation mit dem client

hier wartet der server erstmal auf instruktionen vom clienten ...
so bald diese eintreffen werden diese an eine freie unit weitergeleitet ... sollte zur zeit keine unit frei sein wird dieses commando auf den stack geschrieben ...
der client läuft derweil in IDLE und wartet ganz normal auf antwort vom server ...
dabei muss der con-thread dem client noch nicht mal mitteilen das seine aufgabe auf dem stack liegt ... wenn man beide seiten *server und client* so programmiert das nur reine nutzdaten übertragen werden auf die der jeweils andere mit nem blockierenden aufrauf ala BufferedReader.readLine() wartet ...


Stack-Thread
ist in dem sinne eine zentrale steuerung über den stack und die units ...

der stack-thread weis immer über den aktuellen zustand aller units und den stack selbst bescheid ...
auch ist hier die verwaltung die sich merkt zu welchem con-thread ein auf dem stack liegender befehl gehört ...
mit dieser zusatz information kann dieser thread nach abschluss des befehls das ergebnis an den jeweiligen con-thread weiterleiten

hier läuft im prinzip nur ein loop der die ganze zeit über die units läuft und prüft ob es freie units gibt ... natürlich nur so lange was im stack liegt
gibt es eine freie unit wird ein element vom stack genommen und dieses der unit übergeben ...
auch hier bei muss sich der stack-thread merken welcher befehl von welchem client an welche unit gegangen ist um die kette auch rückwärts weder richtig zusammen zu bekommen


Unit-Thread
arbeitet den befehl ab ...


und ganz erlich ... WO bitte ist jetzt euer problem ?

etwa daran das ihr angst habt das der client wegen nem timeout DC und desshalb eine verbindung vom server zum client aufgebaut werden muss ? völliger schwachsinn

daran das die clienten die einzelnen units direkt kennen müssen ? auch schwachsinn ... dann bräuchtest du den ganzen mist drum rum nicht ... der client kennt nur den server ... und nur der server dient als verbindung zwischen client und unit ... unit und client kennen sich aber nicht dierekt

daran das ganze umzusetzen ? ich habs schon mal gesagt : GOOGLE -> load-balancing ... sollte sich auch was in der form finden lassen

oder besteht das problem einfach nur darin sich diese abläufe im vorfeld bei der konzept-planung vorzustellen und sich dann ein konzept zu überlegen was auch das macht was es soll .. und nicht so ein wildes rumgehampel ...

 

[Michael...]

aber so wirklich von TCP-kommunikation haltet ihr hier alle nichts oder ?

wer ist "hier alle" und wer sollte nichts von TCP Kommunikation halten?

 

[Kr0e]

<sinnlos>

In C++ ginge das

SOCKET *sock = reinterpreter_cast<SOCKET*>(&"ich bin ein socket ");

</sinnlos>

achja und "irgendjemand" will sich mal wieder profilieren

 

[irgendjemand]

wer ist "hier alle" und wer sollte nichts von TCP Kommunikation halten?

das sollte lediglich mal zum ausdruck bringen das hier scheinbar niemand eier in der hose hat um es so einfach zu formulieren ...

wenn du schon so n oberwitzigen quote machst ... warum warst du es dann nicht der das was ich geschrieben habe TO erklärt hat ?

 

[Michael...]

das sollte lediglich mal zum ausdruck bringen das hier scheinbar niemand eier in der hose hat um es so einfach zu formulieren ...

wenn du schon so n oberwitzigen quote machst ... warum warst du es dann nicht der das was ich geschrieben habe TO erklärt hat ?

Das Problem - zumindest nehme ich es an - ist nicht die TCP Kommunikation bzw. die einzelnen Clients abzuarbeiten und zu bedienen, schließlich funktioniert es laut Aussagen des TO bereits wenn die Berechnung direkt auf dem Server abgearbeitet wird.

Daher sehe ich das Problem darin die Aufträge an andere Server zur Berechnung weiterzuleiten und die Ergebnisse wieder zurück an den Anforderer auszuliefern da hier ein Load Balancing bzw. der Betrieb eines Rechenclusters nicht möglich/ gewünscht ist, haben sich meine Vorschäge darauf bezogen wie man die beim Server eingehenden Aufträge an weitere Rechner verteilen und die Ergebnisse wieder an die Anforder zurück übergeben könnte.
Und folgendes habe ich - wenn auch in anderer Form - dem TO ja bereits mitgeteilt:

daran das die clienten die einzelnen units direkt kennen müssen ? auch schwachsinn ... dann bräuchtest du den ganzen mist drum rum nicht ... der client kennt nur den server ... und nur der server dient als verbindung zwischen client und unit ... unit und client kennen sich aber nicht dierekt

 

[Taramsis]

Zuerst mal Danke an alle!

Ich habe es provisorisch hingekriegt. Da ich zur Zeit nur einen Client habe, habe ich den Socket des Clients auf dem Ober-Server gespeichert und jedes ThreadAnfrage, dass zum Client soll, schickt es zu diesem Socket.

Nun suche ich eine geeignete Methode die Sockets für jede ThreadAnfrage zu speichern. Ich schiebe z.B. meine ThreadAnfragen, die zum Unter-Server sollen in eine Queue:

public static Queue<NetworkRequestThread> threadQueue = new LinkedList<NetworkRequestThread>();

Nun dachte ich an soetwas für meine Sockets:

public static Queue<Socket> socketQueue = new LinkedList<Socket>();

Aber hierbei kann man nicht garantieren, dass zur Laufzeit gerade dem einen Thread der richtige Socket zugeordnet wird.

Gibt es LinkedLists mit zwei Elementen?
Bitte seit sanft zu mir, falls ich Eurer Meinung gegen das Java Ethos verstoße:autschnur Spaß!)

 

[irgendjemand]

sorry ... aber du begehst den selben fehler gerade schon wieder ...

es ist nicht aufgabe des controllers den entsprechenden SOCKET zu einem REQUEST zu kennen ... sondern die aufgabe des con-threads der diesen socket offen hält und die brücke zur queue herstellt ...

heißt also : du brauchst EINE queue in dem du objekte eines typs hast die sowohl den request als auch die informationen beihnhalten zu welchem client diese gehören ...

wenn du beides in zwei listen halten willst bekommst du irgendwann sync-probleme ...

 

[SlaterB]

du kannst immer einzelne Objekte einfügen, die auf mehrere andere verweisen, eigene Klassen üblicherweise,

wenn du zu jedem NetworkRequestThread einen Socket brauchst,
wieso dann nicht in NetworkRequestThread eine Variable anlegen?

 

[Taramsis]

Ich mache z.Z. folgendes:

- Nachricht von Client oder "Unter-Server" kommt an starte neuen Thread
- mache Unterscheidung von wem es kommt
- vom Client:
- schiebe in FIFO -- warte auf Reaktivierung vonThread Processing
Reaktiviert: schicke an freien Unter-Server - Thread ende
- vom Unter-Server:
- schicke an Client - Thread ende

- ein Thread Processing prüft, ob FIFO nicht leer und Unter Sevrer Belegung: Reaktiviere nächsten Thread aus FIFO

Ihr meint:
-Nachricht vom Client neuse Thread:
- schiebe in FIFO -- warte auf Reaktivierung vom Con Thread
Reaktiviert:
- schicke an freien Unter-Server
- warte auf Rückmeldung vom Unter-Server
- schicke Rückmeldung an Client - Thread ende


- Con Thread prüft, ob FIFO nicht leer und Unter Sevrer Belegung: Reaktiviere Thread


Hab ich es soweit richtig verstanden?

 

[irgendjemand]

JA ... genau das meine ich ...

denn ganz erlich : wo bitte hat es sinn wenn du den thread welcher eigentlich die verbindung zum client offen halten soll beendest ? dadurch wird auch die verbindung zum client getrennt ... welcher also nie seine daten erhalten wird ...

ich finde dein konzept immer noch sehr wirr und wenig durchdacht ...

nach deinem schema würde sich eine unit beim verteiler melden um ein ergebnis abzuliefern ...
hat für mich zwei nachteile :
1) wenn sich nur die units beim server melden ... der server aber keine dauerhafte verbindung zu den units hat ... woher soll er dann wissen welche unit frei ist ? klar kann man das auch mit nem stack machen ... was aber zu viel aufwand ist ...
2) wenn du : client verbindet sich -> setzt befehl ab -> verbindung wird getrennt -> server kümmert sich um abarbeitung des befehls *zuweisung auf units* -> unit hat irgendwann den befehl abgearbeitet -> meldet sich beim server -> und woher soll jetzt der server wissen wo die daten hin sollen ? selbst wenn du die remote-ip des clienten hast wirst du daran scheitern dich zu diesem zu verbinden ... spätestens an einem NAT-router mit firewall ...

ich glaube du solltest dir noch mal grundlegenden gedanken darüber machen was genau du eigentlich willst ...

im groben kann man dein vorhaben als "load-balancing" verstehen ...
dann mach dir doch bitte mal die mühe dir bei google dazu was rauszusuchen ... weil das was du hier versuchst hat weder sinn noch verstand ... und zeigt eigentlich nur ein katastrophales konzept ...

 

[Taramsis]

Klar macht auch mehr Sinn. War auch nicht aufwebdig es so zu implementieren - Danke!

Ich habe zunächst die Units (zwei) statisch dem "Ober-Server" hinzugefügt. Um das ganze zu automatisieren wollte ich auf dem "Ober-Server" eine Thread starten der permanent nach neuen Units horcht. Sollte eine neue Unit gestartet werden soll nämlich ein String z.B. "free" geschickt werden, danach sollen IP, Port und Status global gespeichert werden.

Meine Frage wäre worin könnte ich das speichern?
Ein zweidimensonales Array, dass man dynamisch vergrößern bzw. verkleiner könnte wäre gut! ArryList fäält mir ein, aber leider sind die nicht zweidimensonal!

 

[irgendjemand]

auch wenn mir nicht einleuchten will warum du das ganze als multi-dimensional brauchst

List<List<?>>=new List<List<?>>();

da hast du deine 2-D liste ...