Was kann SocketChannel was Socket nicht kann?

[Angel4585]

Hallo,

wahrscheinlich eine ganz simple Frage:

Was kann SocketChannel was Socket nicht kann?
Bzw. warum und wann sollte ich anstatt Socket, SocketChannel verwenden?

 

[tuxedo]

Socket = Java IO
SocketChannel = Java Native IO

Letzteres kann beispielsweise ohne extra Thread pro Client auskommen und ist daher für große Server besser geeignet:

http://java.sun.com/j2se/1.4.2/docs/guide/nio/

The new I/O (NIO) APIs introduced in v 1.4 provide new features and improved performance in the areas of buffer management, scalable network and file I/O, character-set support, and regular-expression matching. The NIO APIs supplement the I/O facilities in the java.io package.

 

[Angel4585]

hmm.. wenn ich nicht mehrere Threads habe, wie sieht das dann aus bei zB 1.000 Clients?
Ich habe dann doch nach wievor einen Thread der die eingehenden Verbindungen akzeptiert, aber was tut er dann mit dieser Verbindung wenn er keinen neuen Thread erzeugt?
Eine kleine Liste mit den Dingen die ich für ein solches System brauche wäre KLasse damit ich das Prinzip verstehe, kurz in Stichpunkten was ich brauche und was das jeweilige tut.

Also

1. "ConnectionThread": nimmt Verbindungen an und übergibt Verbindung..(??)

 

[tuxedo]

Du musst mit Java NIO umdenken... Aber das hatten wir hier schonmal im Forum (stand vor dem gleichen Problem). Ich bin so gütig und such dir mal den Thread raus.

*suchengeh*

*gefunden*

http://www.java-forum.org/de/viewtopic.php?t=54033

Gruß
Alex

 

[Angel4585]

Achso, OK, das heisst es gibt jetzt anstatt einem Thread pro Client, einen Thread pro 10 Clients oder so?
In dem dieser Thread erstellt dann eine Liste der abzuarbeitenden Aktionen und übergibt diese Wiederum einem Thread der diese Aktionen ausführt?

 

[tuxedo]

Die Anzahl der Threads kannst du ja selbst bestimmen. Wichtig ist nur, dass man nicht für jeden Client zwingend einen eigenen Thread braucht.

Hast du den Artikel den Franz in obigen Link gepostet hat gelesen?
-> http://today.java.net/cs/user/print/a/350

Wenn du das gelesen hast, müsstest du auch auf den Tricher gekommen sein dass NIO ne "coole" Sache ist.

Bisher mit dem alten IO, hast du einen Thread pro Client. In jedem Thread wird "blockierend" gewartet bis Daten eingegangen sind.

Im neuen NIO, kann man einen EventHanlder einbauen der beispielsweise alle Clients überwacht. Hast du beispielsweise 1000 Clients, hast du dann nicht mehr 1000 Threads (einen pro Client), sondern kannst in einem Thread schauen welcher Client gerade bedient werden will. Und dann kannst du beispielsweise immer 10 zu bedienende Clients mit einem Thread abdecken (soll heißen dieser Eine Thread kümmer sich um 10 Clients, ohne 10 weitere Thread zu erstellen. Wäre ja sonst nix anderes wie das alte Java IO).

In Bezug auf dieses Beispiel nochmal der Vergleich:

Nehmen wir 1000 Clients an. Von diesen 1000 Clients wollen just in diesem Moment 15 Clients Daten austauschen... Wieviele Threads brauch ich dann?

Java IO:
Pro Client ein Thread -> 1000 Threads
Denn ich weiß ja nicht welcher Client gerade Daten austauschen will...

Java NIO:
Einen Thread für die Überwachung _aller_ Clients und zwei weitere Threads um die Clients zu bedienen: 15 Clients wollen bedient werden, wir haben die Anwendung jedoch so gestaltet dass pro Bedien-Thread 10 Clients bedient werden können, also brauchen wir 2 Bedienthreads. Macht zusammen 3 Threads.

Du siehst: Willst du einen Server haben, der seeeehr viele Clients verkraftet, dann kommt man mit Java IO schnell an seine Grenzen. Weil irgendwann ist man an einem Punkt angelangt wo man einfach keine neuen Threads mehr erstellen kann und das System aus allen Nähten platzt.
Java NIO hat das Methoden und Ansätze das geschickter zu lösen.

Aber wie gesagt, ließ den Artikel, dann siehst du was ich meine ;-)


Gruß Alex

 

[Angel4585]

OK, ich habe jetzt drei Klassen:

Acceptor(Thread:Wartet auf "Verbindungen")
Connection(Thread: beinhaltet mehrere "Verbindungen")
Controller(verwaltet Acceptor und mehrere Connection)

Das ganze läuft noch nicht, lässt sich aber compilieren.
Die Frage jetzt ist:

Das Konstrukt was ich da hab ist ja der "Server".
Aber wie muss der Client aussehen?
Auf dem Server hab ich ja jede Menge Zeugs mit Selector un was weis ich was alles..
Was braucht der Client um zu schreiben und zu lesen?

 

[tuxedo]

Ich hab NIO selbst noch nicht ausprobiert, aber da es ja nach wie vor eine Socketverbindung ist, kannst du den Client mit dem alten Java IO schreiben. Das "komplexe" ist ja hauptsächlich auf der Server-Seite.

- Alex

 

[Angel4585]

Naja um das Ganze besser zu verstehen möchte ich schon beides mit der nio schreiben..

BTW: An welcher Stelle kommen jetz eigentlich die Daten rein wenn ich was vom Client sende?
Im Acceptor prüfe ich ja nur auf "isAcceptable()" irgendwo muss doch der Selector geprüft werden und auf "isReadable()" geprüft werden oder?

 

[Angel4585]

Also ich habe mir die drei Klassen in dem Thread mal angeschaut und nachgebaut.

Kann mir jemand folgende Zeilen erklären?

    public ServerConnectionAccept(ServerController _selector, int port) throws SocketException 
    {
        try {
            ReadSelector = _selector;
            PORT = port;
            ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
            serverSocketChannel.configureBlocking(false);

            serverSocket = serverSocketChannel.socket();
            InetSocketAddress inetSocketAddress = new InetSocketAddress(PORT);
            serverSocket.bind(inetSocketAddress);
            serverSocket = serverSocketChannel.socket();//Warum diese Zeile? Was passiert hier? Er hat den socket doch schon
            selector = Selector.open();
            serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);
        } catch (Exception e) {
            throw new SocketException("Server Setup fehlgeschlagen.");
        }
    }

 

[Angel4585]

Noch eine Verständnisfrage zum Selector:

selector = Selector.open(); // Neuer Selector wird erzeugt
serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT); //Dem Selector wird die Operation "Accept" zugeordnet

heisst das, dass wenn ein Client ein connect aufruft die Anfrage bei diesem Selector als Key eingetragen wird?

Das würde heissen:

socketselector = Selector.open();
SocketChannel channel = channelList.get(index);
channel.configureBlocking(false);
channel.socket().setReceiveBufferSize(2*1024);
channel.socket().setSendBufferSize(2*1024);
clientKey = channel.register(socketselector , SelectionKey.OP_READ);

An dieser Stelle wird dann, wenn das Gegenüber des Sockets was sendet, beim socketselector ein Key für die Leseanfrage eingetragen, oder?

Also wennd as stimmt hab ichs glaub ich kapiert.

 

[Angel4585]

OK ich hab jetzt kapiert wie das geht.. nur ein Problem hab ich noch:
Wie soll ich vom Server aus an den Client senden?

clientKey = channel.register(socketselector , SelectionKey.OP_READ|SelectionKey.OP_WRITE);

wenn ich das so mache und dann per isWritable() prüfe ob was zu schreiben ist, wird mir dieser channel bei jedem select vom Selector ausgewählt als wenn was zu schreiben wäre, da das nicht oft vorkommt das was zu schreiben ist ist das total unnötig.

Also wie wird geregelt das nur wenn wirklich was zu schreiben ist auch was geschrieben wird?