|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Wie findet Ihr dieses Projekt? |
Super |
|
70% |
[ 12 ] |
Gut |
|
29% |
[ 5 ] |
Mittelmässig |
|
0% |
[ 0 ] |
Schlecht (Warum?) |
|
0% |
[ 0 ] |
Scheisse (Warum?) |
|
0% |
[ 0 ] |
|
Stimmen insgesamt : 17 |
|
Autor |
Nachricht |
Löwe
Anmeldungsdatum: 20.06.2011 Beiträge: 10
|
Verfasst am: 23.07.2011, 17:41 Titel: |
|
|
Hi
Mir ist ein kleiner Bug/Fehler aufgefallen.
Es handelt sich um die Vergabe der Player_IDs
Nehmen wir einmal an ,wir erstellen einen Server mit einer
maximalen Spielerzahl von 3. Damit können wir 2 weitere
Clients "anmelden"
1 -> Server_ID
2 -> Offene Player_ID
3 -> Offene Player_ID
Nun erstellen wir 2 Clients und verbinden diese mit den Server.
1 -> Server_ID
2 -> Vergebene Player_ID
3 -> Vergebene Player_ID
Wenn wir versuchen würden einen weiteren Client zu verbinden,
kommt natürlich keine Verbindung zu stande, da ja alle ID vergeben sind.
Alles so wie es sein sollte.
Wenn nun der Client mit der ID=2 geschlossen wird, sieht es so aus.
1 -> Server_ID
2 -> Offene Player_ID
3 -> Vergebene Player_ID
Jedoch wenn wir nun einen Client mit den Server verbinden,
erhält der Client die ID 4, die es ja gar nicht gibt
und der Server stützt ab.
Anscheinend vergibt der Server die IDs immer aufsteigend, ohne zu
kontrollieren, ob eine bereits vergebende ID wieder frei geworden ist.
Die Verbindung wird wie in deinem Test_play geschlossen.
Wäre gut, wenn du mal danach schauen würdest |
|
Nach oben |
|
|
RWK
Anmeldungsdatum: 04.07.2011 Beiträge: 44
|
Verfasst am: 26.07.2011, 13:42 Titel: |
|
|
Also ich könnte schwören ich hab das seinerzeit auch mal probiert....allerdings mit 10 Clients.
Nachdem die 10 ID's voll waren ist der Server beim nächsten Connect hergegangen und hat wieder die unterste freie ID benutzt.
Aber vielleicht irre ich mich auch.
Ich hätt aber auch noch ne Frage.... wo bei meinem LaufProgramm ja jetzt mehr die Feinarbeit ansteht.
Wenn jetzt aus welchem Grund auch immer....
z.B. der Connect über die WLAN Verbindung am Client bricht ab.
was würde man am sinnigsten machen, um einen ReConnect herzustellen ?
im Disconnect Callback den Abbruch bemerken und irgendwo in einem Thread warten, ob der Server wieder auftaucht ?
Eventuell gibts ja im TSNE auch eine entsprechende Funktion ?
und im schlimmsten Fall, wenn während eines Laufes der Server wegschmiert....Stromausfall..
Alle Clientverbindungen speichern und später Connect senden, das ich wieder da bin ?
Grüße
Rainer
P.S. hab gerade in einem anderen Thread die Objekterkennung gesehen....
http://mln.ath.cx/1.png
also wenn da mal eine andere Versuchsteststellung gesucht wird... z.b. Startnummernerkennung von einlaufenden Läufern |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 26.07.2011, 14:24 Titel: |
|
|
@Löwe
also .. ich habe jetzt mal deinen Fund untersucht, und kann ich leider so nicht bestätigen. Der Fehler zeigt sich bei mir nicht.
Habe diverse Kombinationen ausprobiert, aber die Clienten und der Server liefen problemlos.
Bezüglich der Aufsteigenden Nummer:
Ja, der Server vergibt grundsätzlich aufsteigende Nummern. Das soll verhindern, das zum einen die Programmierer welche mit TSNEPlay arbeiten, die Player-ID Nummern als Indexnummer für Array's nutzen (was zu blauäugigen Fehlern führen könnte, (fehlerhaft gelerte oder reinizialisierte Array-Item's mit alten Daten)
und zum anderen soll es helfen, das Verbinungsprobleme leichter erkannt werden.
Würde ein Client disconencten udn wieder connecten, könnte es bei annahme 1 zu fehlern kommen, wenn mit Array's gearbeitet wird, und in diesem noch daten der vorherigen verbindung zu finden sind (passwörter, usernames, spielstände, usw.) des zuvor getrennten spielers. Hier würde eine möglichkeit geschaffen, das ein user betrügen könnte.
zu 2 ... es ist einfacher bei tests mit z.B. 2 clienten, herauszufinden (wenn massive debuging-texte raus rollen), ob ein disconenct oder connect ereigniss statgefunden hat. Anhand der nummer kann man schon erkennen, ob dies eintrat.
zu der Kontrolle dieser Numern:
Die Nummern werden fortlaufend vergeben.
hierbei wird die nummer durch den aufruf des New_Connection events in TSNEPlay von (TSNE gesendet) über die Funktion -> "TSNEPlay_INT_ClientAdd()" erzeugt.
In dieser Funktion wird die PlayerID um +1 erhöht.
Anschliessend beginnt eien Do-Loop schleife einen Pointer auf die Interne Datenstruktur zu erhalten welche diese "neue" ID enthält. Wird einPointer gefunden, wird von vorn begonnen und die ID nochmals um +1 erhöht.
Dies wird solange wiederholt, bis kein Pointer gefunden wurde, und damit eine datenstruktur in TSNEPLay nicht vorhanden ist. Dies ist gleichzusetzen mit "Diese nummer ist frei".
Dieses Verfahren greift allerdings effektiv erst, wenn min. 2^32 Verbindugen zustande kamen. (Maximaler wert eines UInteger)
Aber, hierfür muss ein Server schon enorm lange laufen. (meiner Meinung nach, wenn das überhaupt irgend wann mal eintreten sollte. ) Aber, würde mich sehr freuen, wenn etwas so populär wird, das es dieses Limit irgend wann mal erreichen würde
@RWK
Regulär sollte die ID wie schon erwählt, bis 2^32 durchlaufen. Das sind gute 4.294.967.296 !!! Verbindungen in einem Serverleben.
Die EInfachste Variante eine Verbindung erneut zu inizialisieren ist dies über das Disconnect event.
Wenn eine Verbindung zusammenbricht erzeugt dies ein Disconnect. Hier kann man gleich darauf einen Reconnect versuchen. (vorwiegend in einer schleife mit einer wartezeit von typisch 1sek.)
Variante um einen Server zu starten, oder einen abgebrochenen Server zu reanimieren:
Code: |
Dim RV as Integer
Do
RV = TSNE_Create_Server(ServerTSNEID, Port, 100, @TSNE_NewConnection)
If RV = TSNE_Const_NoError Then Exit Do
Sleep 1000, 1
Loop
|
für die Clientseite:
Code: |
Sub TSNE_Disconnected(ByVal V_TSNEID as UInteger)
Dim RV as Integer
Do
RV = TSNE_Create_Client(ClientTSNEID, HOSTorIPA, Port, @TSNE_Disconnected, @TSNE_Connected, @TSNE_NewData, 60)
If RV = TSNE_Const_NoError Then Exit Do
Sleep 1000, 1
Loop
End Sub
|
Im Clienten steht hier der Letzte Wert (60) für den "Timeout" ... Unter Linux scheint dies gut zu funktionieren, unter Windows weigert sich das Socket irgend wie (habs noch nicht richtig zum laufen gebracht)
Allerdigns lässt sich hier ein Limit für den Verbindungsaufbau setzen.
Typisch, und im Internet vorherschend sind es 60sek. (sollte auch bei Verbindungen übers internet nicht verändert werden!)
Im Lokalem Netzwerk kann hier deutlich reduziert werden. z.B. auf 2-5sek. (für 100MBit ... bzw. je nach netzwerkspeed und Auslastung im Netzwerk.)
Sollte inerhalb von 2-5sek. entsprechend keine Verbindung zustande kommen, bricht der vorgang ab, und wird dank der Do-Loop schleife erneut gestartet.
Unterschied zum Timeout von 60sek. ist folgender:
TCP/IP Sendet beim aufruf einer Verbindungsanfrage zu einem Server eine solche Nachricht über das Netzwerk.
Je nach netzwerkauslastung kann dies (z.B. nach china) schon mal einige sekunden dauern (10, 20, 30, ... je nachdem). Diese Zeit darf bis zu 60sek. (RFC festgelegt) dauern. Wird in dieser Zeit keine Antwort erhalten wird davon ausgegangen, das kein Server erreichbar ist (anfrage wurde ignoriert, oder konnte sein ziel in 60sek. nicht erreichen (überlastung)).
Daraufhin erhält TSNE eine Fehlermeldung, und bricht den Vorgang mit einer eigenen Meldung an den Programmierer ab. (Timeout)
Da man jedoch im Lokalem Netzwerk davon ausgehen kann, das die Verbindungen udn Auslastung im eigenen Netzwerk keinesfalls so dramatisch hoch sind, das man schonmal 60sek. auf ne antwort warten muss, kann man die Zeit deutlich herunter schrauben.
Das hat natürlich zur folge, das nach 5sek antwortlosem gewarte, ein neuer schleifendurchlauf beginnt, und sofort wieder ein neues Packet gesendet wird.
Dieses vorgehen ist hilfreich, wenn es, wie bei dir, um ein WLAN Handelt, bei welchem schonmal die verbindung zusammenbrechen kann, aber noch im Lokalem Netzwerk arbeitet.
Zwar kann es über das WLAN auch mal zu längeren Antwortzeiten kommen, aber diese sollten eigentlich im Rahmen bleiben.
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
|
Löwe
Anmeldungsdatum: 20.06.2011 Beiträge: 10
|
Verfasst am: 02.08.2011, 18:47 Titel: |
|
|
ok das leuchet ein
hab aber nochmal eine andere frage:
Ist es schneller viele kleine Datensätze zu senden oder einen großen,
sprich:
---------
SEND A
SEND B
---------
oder
---------
SEND A+B
---------
mfg. |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 02.08.2011, 19:47 Titel: |
|
|
von der Transferrate her ist es ökonomischer, und deutlich schneller, grosse Datensätze zu verschicken. Du kannst sie natürlich in Blöcke kapseln, wenn sie zu gross werden.
Ein Standard Netzwerk-Paket hat eine Grösse von 1518 Byte pro IP-Paket incl. Header informationen.
Wird ein Datenblock mit TSNE übertragen (in einem TSNE_Data_Send aufruf), zerschneidet TSNE selbstständig die Packete (wenn sie grösser als 7936 Byte sind) in 7936 Byte (TSNE_INT_BufferSize) Grosse Blöcke und gibt sie an das TCP oder UDP Socket zur Übertragung weiter.
Dieses Socket zerlegt daraufhin die Datenpackete wiederum in ca. 1480 Byte Grosse blöcke, versieht sie mit weiteren Kopf-Informationen und verschickt diese dann über das Netzwerk. Die Kopfinformationen enthalten hierbei Internet-Protokoll Informationen und TCP-/UDP-Protokoll Informationen.
Aus sicht von TSNE ist es eigentlich egal, wie gross die Daten sind, welche du verschicken möchtest. Es zerschneidet die Daten selbstständig und verschickt sie entsprechend passend.
Einzigst wenn die Blöcke Kleiner als 1480 Byte werden, wird es nachteilig, wenn man Daten schickt, weil das eigetnlcihe Datenpaket welches über das Netzwerk verschickt wird, nicht bis zum rand gefüllt (ausgereizt) ist.
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
|
Domso
Anmeldungsdatum: 02.02.2011 Beiträge: 109
|
Verfasst am: 05.09.2012, 20:55 Titel: |
|
|
sollte man vielleicht hier ergänzen... hatte nämlich mit fb 0.24 das selbe problem mit tsne_play... und musste auch erstmal nach der Lösung suchen |
|
Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007 Beiträge: 1837 Wohnort: [JN58JR]
|
Verfasst am: 05.09.2012, 21:03 Titel: |
|
|
Habs auch zusätzlich mal auf den Ersten Post gepackt.
THX!
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
|
Domso
Anmeldungsdatum: 02.02.2011 Beiträge: 109
|
Verfasst am: 08.12.2013, 17:18 Titel: |
|
|
kann es sein, dass TSNEPlay_SendData() zu einem speicherüberlauf führt? zumindest wenn man zb. in die testplay.bas einfach in die schleife
TSNEPlay_SendData(x,"testtesttesttesttest") schreibt, vergrößert sich der speicher ziemlich schnelll... auch wenn man "sleep 1000,1" einfügt, verändert sich nichts (geht nur langsamer...) |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|