Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

[ Win/Linux ][ Netzwerk ] TSNEPlay - Netzwerk für Spiele
Gehe zu Seite Zurück  1, 2, 3
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Projektvorstellungen
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  

Wie findet Ihr dieses Projekt?
Super
70%
 70%  [ 12 ]
Gut
29%
 29%  [ 5 ]
Mittelmässig
0%
 0%  [ 0 ]
Schlecht (Warum?)
0%
 0%  [ 0 ]
Scheisse (Warum?)
0%
 0%  [ 0 ]
Stimmen insgesamt : 17

Autor Nachricht
Löwe



Anmeldungsdatum: 20.06.2011
Beiträge: 10

BeitragVerfasst am: 23.07.2011, 16:41    Titel: Antworten mit Zitat

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 zwinkern
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
RWK



Anmeldungsdatum: 04.07.2011
Beiträge: 44

BeitragVerfasst am: 26.07.2011, 12:42    Titel: Antworten mit Zitat

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 lächeln lächeln lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1837
Wohnort: [JN58JR]

BeitragVerfasst am: 26.07.2011, 13:24    Titel: Antworten mit Zitat

@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. grinsen ) Aber, würde mich sehr freuen, wenn etwas so populär wird, das es dieses Limit irgend wann mal erreichen würde cool


@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
Benutzer-Profile anzeigen Private Nachricht senden
Löwe



Anmeldungsdatum: 20.06.2011
Beiträge: 10

BeitragVerfasst am: 02.08.2011, 17:47    Titel: Antworten mit Zitat

ok das leuchet ein zwinkern
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
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1837
Wohnort: [JN58JR]

BeitragVerfasst am: 02.08.2011, 18:47    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Domso



Anmeldungsdatum: 02.02.2011
Beiträge: 109

BeitragVerfasst am: 05.09.2012, 19:55    Titel: Antworten mit Zitat

Zitat:

25.08.2012
KRITISCHE FEHLERBEHEBUNG

* TSNE_INT_Thread_Master wurde mit einem Parameter versehen, ohne welchem es ab FBC 0.24 zu einem Crash fürte.


Hierzu die aktuelle Version: http://www.freebasic-portal.de/porticula/tsnev3-bi-1548.html



MfG
TPM


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 lachen
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1837
Wohnort: [JN58JR]

BeitragVerfasst am: 05.09.2012, 20:03    Titel: Antworten mit Zitat

Habs auch zusätzlich mal auf den Ersten Post gepackt.

THX!


MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Domso



Anmeldungsdatum: 02.02.2011
Beiträge: 109

BeitragVerfasst am: 08.12.2013, 16:18    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Projektvorstellungen Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite Zurück  1, 2, 3
Seite 3 von 3

 
Gehe zu:  
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.

 Impressum :: Datenschutz