PureBoard

@Zigapeda: bist du denn noch zu retten?
Schon bei nem absoluten Traumping von 50ms würde der Ping somit auf 300ms ansteigen. Und damit willst du CounterStrike spielen? Gute Nacht, und träum schön von meinem Headshot...

Ich hab öfters mal nen Ping von 180ms, dh. mit deiner "Netzwerkandwendung" hätte ich also nen Ping von 430ms. Wenn man jetzt bedenkt, dass man auf vielen Serern schon ab nem Ping von 120-150ms gekickt wird, dann kann man mit sowas ja gar net mehr CounterStrike spielen.
Und selbst für nen normalen Dateitransfer wäre mir ein Ping von fast ner halben Sekunde viel zu gewagt...

Zu diesem Thema findet sich auch unter Tutorials auf PureArea ein Text zu WaitWindowEvent und WindowEvent:

Direktlink:

http://www.purearea.net/pb/download/tut ... ndling.htm

hardfalcon hat geschrieben:@Zigapeda: bist du denn noch zu retten?
Schon bei nem absoluten Traumping von 50ms würde der Ping somit auf 300ms ansteigen. Und damit willst du CounterStrike spielen? Gute Nacht, und träum schön von meinem Headshot...

Ich hab öfters mal nen Ping von 180ms, dh. mit deiner "Netzwerkandwendung" hätte ich also nen Ping von 430ms. Wenn man jetzt bedenkt, dass man auf vielen Serern schon ab nem Ping von 120-150ms gekickt wird, dann kann man mit sowas ja gar net mehr CounterStrike spielen.
Und selbst für nen normalen Dateitransfer wäre mir ein Ping von fast ner halben Sekunde viel zu gewagt...

oh nein, der chat hat die nachricht 17 millisekunden später ausgespukt als sie gekommen ist.
HF: spielst du CS in nem Window und nicht mit Vollbildschirm?

Threads sind trozdem nicht wirklich empfehlenswert ...

zigapeda hat geschrieben:

hardfalcon hat geschrieben:@Zigapeda: bist du denn noch zu retten?
Schon bei nem absoluten Traumping von 50ms würde der Ping somit auf 300ms ansteigen. Und damit willst du CounterStrike spielen? Gute Nacht, und träum schön von meinem Headshot...

Ich hab öfters mal nen Ping von 180ms, dh. mit deiner "Netzwerkandwendung" hätte ich also nen Ping von 430ms. Wenn man jetzt bedenkt, dass man auf vielen Serern schon ab nem Ping von 120-150ms gekickt wird, dann kann man mit sowas ja gar net mehr CounterStrike spielen.
Und selbst für nen normalen Dateitransfer wäre mir ein Ping von fast ner halben Sekunde viel zu gewagt...

oh nein, der chat hat die nachricht 17 millisekunden später ausgespukt als sie gekommen ist.
HF: spielst du CS in nem Window und nicht mit Vollbildschirm?

Mal nen kleines Rechenbeispiel:
Eine Datei von rund 600 MB aufgeteilt in 1024 Bytes große Packete und einem delay von 1 hätte schon eine verzögerung von 586 Sekunden ausgemacht. Was das dann bei einem noch höheren Delay bedeuten würde kann ja nun jedere selber ausrechnen....

also das liegt aber dann am protokoll auserdem wenn ich mir 600 MB runterlade dann kann ich eine verzögerung von 568 sekunden ruhig verkraften wenn das bei einem normalen DSL anschluss (1000kbit/s) eh mindestend 2 Stunden.

Hm hat eigentlich weniger mit dem protokoll zu tun, TCP/IP wird dir niemals 600 MB als ein ganzes Datenpaket senden. Dazwischen wird es hundertemale zum #WSAWouldBlock kommen und es ist ja auch nur ein Rechenbeispielt für EINE Datei. Hängt immer von ab was programmiert wird. Für einen Server der 100% Leitung in spitzen Zeiten bringen muss ist ein Delay(1) nicht akzeptabel.

hast du aber auch die Schattenseite bedacht ?
Der Server sendet dir permanent kleine Datenblöcke. Wenn du dann noch
die richtige Leitung hast, dann kommt bei jeder Abfrage ein neues Paket
an. Wenn dann die ganze Zeit Pakete ankommen ist die CPU dauerhaft
mit mindestens 100% Kapazität ausgelastet.

auserdem hat das delay ja nur zur folge das nicht x mal in der sekunde überprüft wird ob was angekommen ist.
wenn ein packet angekommen ist muss man es hald so schreiben das befor es wieder ein delay macht schaut ob noch mehr angekommen ist d.h. am schluss kommt höchstens bei einem delay von 250 eine verzögerung von einer viertel sekunde rauskommen und das merkt man nicht!

Ihr diskutiert immer noch, ob 1 oder 250, nehmt 0

MSDN hat geschrieben:A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution