Ist das State Design Pattern angesichts von TCP von geringem Nutzen, wenn IO nicht blockiert ist?

Question

In meiner TCP-Anwendung schien das Entwurfsmuster State nützlich zu sein, solange IO blockiert wurde.

Die Funktion doInBackground() meines SwingWorkers könnte eine Schleife durch die Lese-, Schreib- und Akzeptanzzustände der TCP-Verbindung durch Verweis auf das eine Objekt durchlaufen. Siehe das Beispiel auf der Wikipedia-Talk-Seite: http://en.wikipedia.org/wiki/Talk%3AState_pattern .

Als ich jedoch den Server auf nicht blockierende IO umstellte, schien dies nicht mehr sinnvoll. Select() gab eine Gruppe von Kanälen zurück, die für IO bereit waren, und diese wurden durch Verweise auf SelectionKey-Zustände in einer Reihe von if-Anweisungen behandelt.

Kann jemand aus Erfahrung oder Verständnis bestätigen, ob State Design Pattern noch Nutzen hat, wenn IO nicht blockiert ist?

Ich frage, weil ich mir nicht sicher bin, ob ich das State Design Pattern und die Beziehung zu TCP richtig verstanden habe.

Answer 1

Immer noch sehr nützlich, man hat nur einen Zustandsautomaten pro Verbindung. select(2) (o poll(2) o epoll(7) ) geben Ihnen nur eine Möglichkeit, auf mehrere Kanäle zu warten und Ereignisse an diese Zustandsautomaten zu senden.