Socket Kommunikation

[izoards]

Hallo,

Ich lasse ein Socket Server auf einem Raspberry pi laufen.
Im Construktor erwarte ich eine identifikation, nur dann wird die Verbindung hergestellt.
Leider musste ich feststellen, dass sich viele fremde IP‘s verbinden möchte, die meisten kann ich so nach der falscheingabe direkt schliessen.

Jedoch gibt es einige, die sich verbinden und nichts senden, somit blockiert das mein Server.
Nun wollte ich dies mit einem Timeout lösen, leidr gilt das timeout dann global.

Mein Ziel wäre, nur beim ersten lesen ein timeout einzubauen.
Muss ich das über einen zweiten thread machen?
Oder was ist das einfachste?

Danke für die Hilfe

 

[httpdigest]

How to timeout a read on Java Socket?

I'm trying to read items from a socket and I notice that if there is nothing on the stream of the socket it will stay at the read and back up my application. I wanted to know if there was a way to ...

stackoverflow.com

 

[Jw456]

Wenn sich mehrere Clains verbinden können sollen solltest du jeden Verbindung in einen Thread halten. Sonnst ist der Server belegt.

 

[KonradN]

Also generell ist zu empfehlen, die neuen Channel aus dem nio Package zu nutzen.

Jeder Client ein Thread ist bei vielen Clients extrem suboptimal!

 

[mrBrown]

Also generell ist zu empfehlen, die neuen Channel aus dem nio Package zu nutzen.

Jeder Client ein Thread ist bei vielen Clients extrem suboptimal!

Bis Project Loom fertig ist

 

[KonradN]

Bis Project Loom fertig ist

Wird das so Probleme lösen? Ich habe mich da noch nicht im Detail mit beschäftigt.

Das Problem ist doch generell, dass man auch bei "virtuellen Threads" diese verwalten muss incl. Locks und Umschalten. Das mag dann zwar eine Besserung bringen, aber ob und wie dies Probleme wirklich löst? Ich selbst sehe das relativ skeptisch.

Da ist es eher Erfolgversprechend, wenn man bei der sync API versucht, so viele Blocks wie möglich zu verhindern (Das geht relativ gut - meine Tests sahen da sehr vielversprechend aus! Habe ich aber nur relativ kurz angetestet). Der Call, Verbindungen anzunehmen, blockiert immer - das ist also ein Thread. Beim lesen prüft man erst, ob und wieviel da ist und liest dann -> Lesen Blockiert nicht! Schreiben wird dann noch einmal kritisch - da hat man so erst einmal zu wenig Kontrolle über die zugrunde liegenden Buffer fand ich. Aber da kann man mit einem Threadpool arbeiten wobei ein Thread nur blockierte Worker abhandelt und die blockierte Verbindung schließt. Das endet auch der blockierte Thread.

Aber es wird schnell deutlich: Das ist unnötiger Aufwand / hohe Komplexität. Dazu haben wir ja die Channel bekommen mit Java 7 (??).

Gibt es in Java Kreisen eigentlich Diskussionen, das async / await einzuführen, das ja in immer mehr Sprachen Einzug gefunden hat? Da habe ich so auf Anhieb nichts zu gefunden....

 

[Flown]

Das Problem ist doch generell, dass man auch bei "virtuellen Threads" diese verwalten muss incl. Locks und Umschalten. Das mag dann zwar eine Besserung bringen, aber ob und wie dies Probleme wirklich löst? Ich selbst sehe das relativ skeptisch.

Ja wird es. Siehe ein sehr gutes Beispiel: Vert.X (sorry war vorher Jetty)

 

[KonradN]

Ja wird es. Siehe ein sehr gutes Beispiel: Jetty

Kannst Du das erläutern? Jetty nutzt ja keine blockierenden Calls mit vielen Threads sondern nutzt auch die Channel. So verstehe ich zumindest

Jetty 11 Programming Guide :: Eclipse Jetty

www.eclipse.org

 

[Flown]

Kannst Du das erläutern? Jetty nutzt ja keine blockierenden Calls mit vielen Threads sondern nutzt auch die Channel. So verstehe ich zumindest

Jetty 11 Programming Guide :: Eclipse Jetty

www.eclipse.org

Ja sorry... Ich hab mich vertan .... ich meinte natürlich Vert.x ... das ist auch die Engine unter Quarkus und die hat eben statt Thread/Request selbst "virtuelle" Threads gebastelt in einer Eventloop.
Auf der Seite sieht man sogar wie "idle" time reduziert wird. Und wir in der Arbeit merken schon den Unterschied, wenn man von OpenShift die MilliCores und Threadpools reduzieren kann, wenn man von EAP -> Quarkus geht (Real-Life Beipsiel aus eigener Erfahrung).

 

[KonradN]

Ah ok, werde ich mir dann auch mal bei Gelegenheit ansehen.

 

[izoards]

How to timeout a read on Java Socket?

I'm trying to read items from a socket and I notice that if there is nothing on the stream of the socket it will stay at the read and back up my application. I wanted to know if there was a way to ...

stackoverflow.com

Das habe ich bereits versucht, das timeout kommt dann aber immer.. also bei mir läuft halt nicht viel traffic, d.h. Wenn ich mit dem timeout arbeite, wird dieses immer wieder kommen, solange keine kommunikation läuft, ich möchte das aber nur beim ersten mal. Und habe nicht gefunden, wie ich das timeout wieder „löschen“ kann…
Die clients haben einen eigenen Thread..

 

[Oneixee5]

Gibt es in Java Kreisen eigentlich Diskussionen, das async / await einzuführen, das ja in immer mehr Sprachen Einzug gefunden hat? Da habe ich so auf Anhieb nichts zu gefunden....

Electronic Arts hat dafür eine API rausgebracht:

<!-- https://mvnrepository.com/artifact/com.ea.async/ea-async -->
<dependency>
    <groupId>com.ea.async</groupId>
    <artifactId>ea-async</artifactId>
    <version>1.2.3</version>
</dependency>

 

[mrBrown]

Gibt es in Java Kreisen eigentlich Diskussionen, das async / await einzuführen, das ja in immer mehr Sprachen Einzug gefunden hat? Da habe ich so auf Anhieb nichts zu gefunden....

Loom wird die meisten Probleme lösen, für die man aktuell async nutzen würde - nur eben ohne async, sondern mit „ganz normalem“ Code.

 

[mihe7]

When will we be loomed?

 

[KonradN]

Electronic Arts hat dafür eine API rausgebracht:

<!-- https://mvnrepository.com/artifact/com.ea.async/ea-async -->
<dependency>
    <groupId>com.ea.async</groupId>
    <artifactId>ea-async</artifactId>
    <version>1.2.3</version>
</dependency>

Ja, aber das ist wohl tot würde ich behaupten... Letzter Change laut https://github.com/electronicarts/ea-async vor 3 Jahren und unterstützt laut Doku Java 8 - 10.

Daraus schließe ich etwas, dass dies nicht wirklich Anklang gefunden hat und Java Entwickler da eher andere Wege gehen wollen bzw. es einfach ein paar Jahrhunderte länger dauert, bis da irgendwas auch in Java ankommt an Neuerungen ...

 

[KonradN]

Loom wird die meisten Probleme lösen, für die man aktuell async nutzen würde - nur eben ohne async, sondern mit „ganz normalem“ Code.

Da bin ich dann mal gespannt und dann muss ich mir das doch einmal im Detail ansehen.

 

[httpdigest]

Das habe ich bereits versucht, das timeout kommt dann aber immer.. also bei mir läuft halt nicht viel traffic, d.h. Wenn ich mit dem timeout arbeite, wird dieses immer wieder kommen, solange keine kommunikation läuft, ich möchte das aber nur beim ersten mal. Und habe nicht gefunden, wie ich das timeout wieder „löschen“ kann…
Die clients haben einen eigenen Thread..

Bitte einfach immer die Doku lesen: https://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setSoTimeout(int)

Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the InputStream associated with this Socket will block for only this amount of time. If the timeout expires, a java.net.SocketTimeoutException is raised, though the Socket is still valid. The option must be enabled prior to entering the blocking operation to have effect. The timeout must be > 0. A timeout of zero is interpreted as an infinite timeout.

Du kannst zwischen zwei read() Aufrufen jederzeit das Timeout ändern, bzw. auf unendlich setzen, indem du (wie in der Doku angegeben) eine 0 als Argument verwendest.

Trotzdem solltest du dich aber nicht nur auf das Fliegen der Timeout Exception verlassen, sondern ein eigenes Flag mitführen, welches sagt, ob jemand schon die nötigen Authentifizierungsinformationen mitgeschickt hat. Und dann eben das Ganze z.B. in einer while-Schleife mit innerem try-catch auf die Timeout Exception laufen lassen und die while-Schleife nutzt als Bedingung eben das eigene Flag.