[delphi]:Tclientsocket traag, bij alleen ontvangen?

[Ivo-Jonker]

Heej rieder van mn topicje

Goed, zoals de titel al ongeveer verklapt, ik heb tclientsocket problemen!

Wat is het geval, ik ben een simpel spelletje aan het maken waarin meerdere spelers(clients) op een server zitten.

Bij het inloggen stuurt de client 1 keer van hey, hier ben ik, de server bepaald dan of hij erin mag, het zelfde voor het weg gaan. allemaal geen probleem.

Het probleem zit he mechter in het doorsturen van de coordinaten.

De client is maar net een "uitbeelder", hij laat tankjes en kogels zien op plekken waar de server zegt dat ze zijn. zo stuurt de server per tankje per 10 miliseconden (gewoon Ttimer), zijn naam+#30+posX+#30+PosY, een paar bytes dus zeg maar.

Tijdens het testen loopt alles vloeiend, dus dat wil zeggen als ik op localhost verbind gaat alles vlekkeloos, maar toen ik het ben gaan testen over het netwerk, kwam ik tot de conclusie dat alles veelste traag ging.

Het rare is echter wel, dat zodra ik vanaf de client gewoon 'n dummy (clientsocket.socket.sendtext(#1);) ga versturen in de paint procedure (die zo'n 300X per sec doorgelopen wordt) het weer wel lag-vrij gaat.

Enig idee hoe dit komt, en eventueel te verhelpen is?

Hmm, dit is meschien wel 'n beetje vage post opzich, als het te onduidelijk is hoor ik het wel,

groetsels,
Ivo Jonker

[Verwijderd]

Ivo-Jonker schreef op 11 maart 2004 @ 14:16:
De client is maar net een "uitbeelder", hij laat tankjes en kogels zien op plekken waar de server zegt dat ze zijn. zo stuurt de server per tankje per 10 miliseconden (gewoon Ttimer), zijn naam+#30+posX+#30+PosY, een paar bytes dus zeg maar.

Hoeveel TTimers heb je? Eentje per tank of een in het algemeen? Hoeveel tanks zijn er en had je niet beter iedere tank in een eigen thread kunnen laten lopen. Denk daarbij bijv. aan een communicatiethread die de aansturing van alle threads (met bijbehorende tanks) regelt.
Om de 10ms lijkt me sowieso iets te veel van het goede. Probeer eens om de 100 ms.

Tijdens het testen loopt alles vloeiend, dus dat wil zeggen als ik op localhost verbind gaat alles vlekkeloos, maar toen ik het ben gaan testen over het netwerk, kwam ik tot de conclusie dat alles veelste traag ging.

TCP kent best veel controles om alles vlekkeloos te laten communiceren. UDP daarentegen zal veel sneller zijn doordat er minder wordt gecontroleerd. Foutieve datapakketjes kunnen echter wel voorkomen.

Het rare is echter wel, dat zodra ik vanaf de client gewoon 'n dummy (clientsocket.socket.sendtext(#1);) ga versturen in de paint procedure (die zo'n 300X per sec doorgelopen wordt) het weer wel lag-vrij gaat.

Wat bedoel je hier nou precies mee? Dat die 300 bytes wel goed verzonden worden of dat het spel dan in een keer wel snel genoeg draait?

Enig idee hoe dit komt, en eventueel te verhelpen is?

Gooi i.i.g. Timers weg als je er meer als een gebruikt en stap over op threads.

Hmm, dit is meschien wel 'n beetje vage post opzich, als het te onduidelijk is hoor ik het wel,

Inderdaad vrij vaag. Probeer precies duidelijk te maken waar de bottleneck zit en waar je niet uitkomt.

groetsels,
Ivo Jonker

Lees de FAQ en de policy wat betreft groeten doen.

[Ivo-Jonker]

Bedankt voor je reply!

Ik denk niet dat het aan de timers ligt, dit aangezien als je op localhost connect het wel vlekkeloos gaat.

Wat ik dus bedoel is dat zodra ik niet op localhost verbind, dat er dan een redelijke vertraging komt.

Deze vertraging valt weer weg als ik voortdurend de tclientsocket blijf gebruiken door bijvoorbeeld voordurend karaktertjes erover blijf sturen.

Het is meschien inderdaad wel nuttig om het client socket gebeuren als een aparte thread the runnen (of is dit zowiezo het geval?).

Ik zal nog eens verder kijken, tips zijn welkom.

[martijn_brinkers]

probeer eens 'nagle' (TCP_NODELAY ) uit te zetten.

zie oa: http://tinyurl.com/2yukt

[Verwijderd]

Ivo-Jonker schreef op 11 maart 2004 @ 15:53:
Bedankt voor je reply!

Ik denk niet dat het aan de timers ligt, dit aangezien als je op localhost connect het wel vlekkeloos gaat.

Maar localhost is dan ook je local loopback en loopt niet via een nic en kent dus geen vertraging of snelheidsbeperking.

Wat ik dus bedoel is dat zodra ik niet op localhost verbind, dat er dan een redelijke vertraging komt.

Deze vertraging valt weer weg als ik voortdurend de tclientsocket blijf gebruiken door bijvoorbeeld voordurend karaktertjes erover blijf sturen.

Data wordt waarschijnlijk eerst gebuffert en daarna verzonden. Doordat je de pijp continue vult zal de buffer sneller verzonden worden.

Het is meschien inderdaad wel nuttig om het client socket gebeuren als een aparte thread the runnen (of is dit zowiezo het geval?).

Ik zal nog eens verder kijken, tips zijn welkom.

Weet de preciese implementatie van TClientSocket niet maar verwacht wel dat deze een eigen thread heeft.

[Ivo-Jonker]

@Hvdberg
Bedankt Het was inderdaad een soort van buffer.

en TijnFlip gaf het goede antwoord

beide bedankt!


Nog even wat info voor de mensen die eventueel via 'n search op deze topic komen.


TCP_NODELAY

The TCP_NODELAY option is specific to TCP/IP service providers. Enabling the TCP_NODELAY option disables the TCP Nagle Algorithm (and vice versa). The Nagle algorithm (described in RFC 896) is very effective in reducing the number of small packets sent by a host by essentially buffering send data if there is unacknowledged data already "in flight" or until a full-size packet can be sent. It is highly recommended that TCP/IP service providers enable the Nagle Algorithm by default, and for the vast majority of application protocols the Nagle Algorithm can deliver significant performance enhancements. However, for some applications this algorithm can impede performance, and TCP_NODELAY can be used to turn it off. These are applications where many small messages are sent, which need to be received by the peer with the time delays between the messages maintained. Application writers should not set TCP_NODELAY unless the impact of doing so is well-understood and desired, since setting TCP_NODELAY can have a significant negative impact of network and application performance.

delphi code (uses winsock)

setsockopt(socket.SocketHandle, IPPROTO_TCP,TCP_NODELAY, pchar(@SO_True),SizeOf(SO_True));

(SO_true:integer=1)