# IO oder NIO?



## JJJK (17. Jul 2006)

Hallo!

Ich will in den nächsten Monaten meine (nicht besonders weit reichenden) Java-Kenntnisse nochmal weiter vertiefen und überlege, mit ein paar Freunden ein Multiplayerspiel zu schreiben. Ich weiß ungefähr was in  Sachen Netzwerkprogrammierung auf mich zukommt (und was ich noch lernen muss), und da das nicht wenig ist, würd ich jetzt schon gerne mit den Dingen anfangen die ich später auch benutzen werde.
Das Problem ist natürlich der Server und die Frage, wie ich die Verbindungen verwalte. Wenn ich das richtig sehe gibts einmal das Modell mit java.io wo ich für jeden Client einen Thread aufmache, oder eben das nio-Modell wo man theoretisch alles mit einem Thread machen könnte.

Was ist der bessere Ansatz? Was ist effizienter bei höherer Last? Gibts Alternativen?


----------



## Beni (17. Jul 2006)

Naja die API meint zur 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.


Von dem her... ich würde NIO empfehlen.


----------



## millinär (17. Jul 2006)

beim standart io hat man mehr deutsche Tutorials


----------



## Beni (18. Jul 2006)

:shock:  Dann lern english...  :roll:


----------



## millinär (18. Jul 2006)

ich hab ja mit deutsch schon genug propleme lol
aber im ernst ich hab mir wegen dem post mal das Nio package angeschaut und ich hab kein plan wie man oder für was man das benutzt


----------



## JJJK (18. Jul 2006)

Soweit ich das verstehe kann man beim nio
- "direkten" speicher anfordern (also ein buffer optional ohne byte[] drin)
- primitive datentypen einfach als bytes schreiben (und aus bytes lesen), little endian / big endian
- blockweise lesen/schreiben
- verbindungen akzeptieren und daten aus channels (statt streams) lesen ohne zu blockieren (das eigentlich interessante wenns um server geht)
- und sicher noch einiges mehr


----------



## Java Chris (18. Jul 2006)

performance mässig denk ich, kannst du beides nehmen

a) ist der server eh meist einfach nur ein server
b) wird es wirklich so ein mega spiel, dass da so viele verbindungen aufgebaut werden?


----------



## JJJK (18. Jul 2006)

Das nicht, aber man kanns ja auch gleich ordentlich machen   
Sollte ich tatsächsächlich ein (noch so kleines) multiplayerspiel mit zentralem Server hinkriegen, finden sich da schon genug Spieler... Sogar einfache MUDs ziehen auch in den Zeiten von WoW tausende Spieler an (da hab ich nur die Theorie dass die von Leuten gespielt werden die eigentlich arbeiten sollten, das simple Text-Interface aber für den unerfahrenen Manager aussieht als würden sie das auch tun... hehe)

danke für die Antworten, ich glaub ich konzentrier mich auf nio. Anzahl von Tutorials ist nicht unwichtig, aber auf englisch gibts da tatsächlich genug


----------



## Gumble (18. Jul 2006)

Wuerde noch verschiedenene Frameworks/Protokolle zur Aussicht stellen stellen, die sich, OSI maessig, ueber (TCP-)IP bewegen. Sowas wie RMI (remote method invocation) oder gleich per Webservice (xml ueber http) kommunizieren (um Firewallprobleme zu entgehen) - kommt natuerlich auf die Art, die Menge und den 'Echtzeit-Bedarf' der Uebertragung drauf an.


----------



## JJJK (18. Jul 2006)

Naja, ich will unter anderem auch Positionsdaten senden. Obwohl die nicht entscheidend sind, denk ich nach noch nen optionalen Weg über UDP anzubieten...
Da ich nicht vorhab irgendwas allzu komplexes herumzuschicken aber das bischen dann möglichst schnell (und bei den positionsdaten häufig) würd ich auch lieber auf einen allzu dicken Overhead verzichten (auch wenns vermutlich einfacher zu implementieren wär).


----------



## millinär (19. Jul 2006)

das mit den Channels finde ich interessant 
man kriegt bei i/o nur einen Stream pro Socket ich könnte mir also nicht aus einem Socket 2 Streams besorgen die Unterschiedliche Daten Transportieren  
aber mit den Channels könnte ich einen Chanel für z.b: Chat-Text machen und einen Channel für andere Daten oder?


----------



## Java Chris (19. Jul 2006)

warum bekommst du nur einen socket, ein client kann sich doch 2 mal zum server verbinden, dann hast du halt serverseitig 2 verschiedene und der client weiß ja dass er 2 hat...

nun sagst du, nach dem verbindungsaufbau sendet der client seine ID rüber... (timestamp oder sonstiges) und ordnest du beim server zusammen... und schon hast du 2


----------



## millinär (19. Jul 2006)

achso kann brauch man dazu 2 verschiedene ports oder kann man das auch auf einem Port machen?


----------



## JJJK (19. Jul 2006)

man kann auch 2 oder mehr verschiedene typen von informationen senden, denkt man sich eben ein protokoll aus. 

wenn man 2 sockets macht überlässt man das praktischerweise der darunterliegenden netzwerkschicht... aber irgendeinen nachteil gibts da sicher auch...


----------



## Java Chris (20. Jul 2006)

millinär hat gesagt.:
			
		

> achso kann brauch man dazu 2 verschiedene ports oder kann man das auch auf einem Port machen?



naja den port den du da angibst zb 21, ist ja nur der listenerport... die packete laufen dann schlussendlich über irgendwelche anderen ports... jede verbindung = ein port


----------



## Mac Systems (20. Jul 2006)

NIO ist für hardcore IO schon das richtige, gerade wenn du auf diese lässtige accept() in den socket klassen verzichten willst. Du kannst einfach pollen ob was zu lesen oder zu schreiben ist. Ich habe mit NIO so meinen kleinen privat kampf gehabt, letztendlich ist aber die erkenntiss in mir gereift das es in hochperformance kritischen anwendungen einfach besser ist, aber den code deutlich komplexer macht. da du wirklich jeden fall behandeln musst, das kostet einiges an überlegungen und guten testcode. Um mal was bekanntest zu nennen, Applejuice nutzt auch NIO und das mit grund: Vollkommende kontrolle. Die standart IO-API ist ja ganz nett aber hier hat java lange zeit total versagt.

NIO ist alt nicht nur sockets und channels, allein die Klasse RandomAccessfile ist genial um eine gleichzeitiges schreiben und lesen von daten zu unterstützen. Sowas lässt sich in ein MVC model einbauen und in dem RAM mappen.


----------



## Gast (14. Aug 2006)

Junge, ist das hier eine Geisterbahn oder ein Java-Forum? Bitte schreibt doch keinen Unsinn hier rein, wenn ihr's nicht wisst... anderen Usern helft ihr nur, wenn ihr was halbwegs fundiertes reinschreibt. Also, ich gehe mal von hinten nach vorne durch (nur die gröbsten Sachen):
(1) Jede Verbindung = ein port --> Liest man ab und zu, ist aber, sorry, Quatsch. Alle Verbindung laufen über den Port, der beim Erzeugen des ServerSockets angegeben wurde.
(2) Damit ist auch klar, dass ein Client sich zweimal mit dem Server auf dem gleichen Port verbinden kann.
(3) Nur ein Stream pro Socket ist doch normal: Sockets kann man sich vorstellen als direkte 1:1 Verbindungen übers Internet... was soll den da bitte über einen zweiten Stream reinkommen?
(4) Java nio ist bei vielen Connections (mehr als ein paar Hundert Clients am Server) sehr viel schneller als das alte io. Bei wenigen Verbindungen (z.B. 2, 20 oder 200) macht es kaum einen Unterschied, was mann nimmt. Richtig große Server (mehr als z.B. 5000 Connections) gehen mit Standard IO nicht mehr, weil da dann 5000 Thread arbeiten, und die CPU fast die ganze Zeit nur dir Threads hin und her switcht.
Alles klar?


----------



## Leroy42 (14. Aug 2006)

millinär hat gesagt.:
			
		

> ich hab ja mit deutsch schon genug propleme lol



Stimmt: Vor allem im Bezug auf Standar*t*-Wissen.  :bae:


----------

