Probleme mit TCP | Neue Frage

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

Gehe zu Seite 1, 2 Weiter

	Myn Betreff: Probleme mit TCP \| Neue Frage	Sa, Feb 11, 2012 13:24 Antworten mit Zitat
Hallo, ich habe mal wieder ein Problem ;D Für mein Projekt habe ich ein Server / Client System mit TCP verwirklicht. Mein Problem ergibt sich aus den Vorteilen von TCP, nämlich das jeden Message unbedingt ankommen muss etc. Wenn jetzt ein Client z.B das Winows-Fenster verschiebt und das Programm angehalten wird (oder auch den X Button von Windows gedrückt hält, viele möglichkeiten..) das nicht nur der Client dann gestoppt wird, sondern (ich vermute) durch die TCP Verbindung auch der Server und so alle anderen Clients. Das gleiche passiert wenn ein Client falsch connectet und sich aufhängt, dabei wird der Server ebenfalls gefreezt bis der Client geschlossen wird. Gib es Möglichkeiten sowas zu unterbinden?^^

Myn

Betreff: Probleme mit TCP | Neue Frage

Sa, Feb 11, 2012 13:24
Antworten mit Zitat

Hallo,

ich habe mal wieder ein Problem ;D

Für mein Projekt habe ich ein Server / Client System mit TCP verwirklicht.
Mein Problem ergibt sich aus den Vorteilen von TCP, nämlich das jeden Message
unbedingt ankommen muss etc.

Wenn jetzt ein Client z.B das Winows-Fenster verschiebt und das Programm angehalten wird (oder auch den X Button von Windows gedrückt hält, viele möglichkeiten..) das nicht nur der Client dann gestoppt wird, sondern
(ich vermute) durch die TCP Verbindung auch der Server und so alle anderen Clients.

Das gleiche passiert wenn ein Client falsch connectet und sich aufhängt, dabei wird der Server ebenfalls
gefreezt bis der Client geschlossen wird.

Gib es Möglichkeiten sowas zu unterbinden?^^

Zuletzt bearbeitet von Myn am So, Feb 12, 2012 15:03, insgesamt einmal bearbeitet

	Blitzcraft	Sa, Feb 11, 2012 13:44 Antworten mit Zitat
Du könntest das ganze TCP Zeug in ein Programm stecken welches kein Fenster hat und das andere Zeug in ein anderes Programm stecken mit Fenster. Dann musst du die beiden Programme nur noch z.B. über eine Datei kommunizieren lassen, also wenn der User im einen Programm(mit Fenster) was macht, das dann als Befehl in eine Datei stecken und vom anderen Programm(ohne Fenster) auslesen und entsprechend was damit machen lassen.
Screenshot aus meinem ersten Projekt

Blitzcraft

Sa, Feb 11, 2012 13:44
Antworten mit Zitat

Du könntest das ganze TCP Zeug in ein Programm stecken welches kein Fenster hat und
das andere Zeug in ein anderes Programm stecken mit Fenster.

Dann musst du die beiden Programme nur noch z.B. über eine Datei kommunizieren lassen, also
wenn der User im einen Programm(mit Fenster) was macht, das dann als Befehl in eine Datei stecken und
vom anderen Programm(ohne Fenster) auslesen und entsprechend was damit machen lassen.

Screenshot aus meinem ersten Projekt

	Myn	Sa, Feb 11, 2012 13:50 Antworten mit Zitat
Es geht dabei aber um "große" Datenmengen, Positionskoordinaten etc. //Edit Der Server müsste ja nur prüfen ob der STream zum client nicht "angehalten/unterbrochen" ist, so dass er nicht versucht dem Client etwas zu senden.

Myn

Sa, Feb 11, 2012 13:50
Antworten mit Zitat

Es geht dabei aber um "große" Datenmengen, Positionskoordinaten etc.

//Edit
Der Server müsste ja nur prüfen ob der STream zum client nicht "angehalten/unterbrochen" ist, so dass
er nicht versucht dem Client etwas zu senden.

	ZEVS	Sa, Feb 11, 2012 13:55 Antworten mit Zitat
Threads werden durch die Fenster-Geschichten nicht eingeschränkt. ZEVS

ZEVS

Sa, Feb 11, 2012 13:55
Antworten mit Zitat

Threads werden durch die Fenster-Geschichten nicht eingeschränkt.

ZEVS

	Blitzcraft	Sa, Feb 11, 2012 13:58 Antworten mit Zitat
Wenn keine Daten beim Server ankommen , nicht warten, sondern einfach überspingen. Im nächsten Frame könnte ja was angekommen sein.
Screenshot aus meinem ersten Projekt

Blitzcraft

Sa, Feb 11, 2012 13:58
Antworten mit Zitat

Wenn keine Daten beim Server ankommen , nicht warten, sondern einfach überspingen.
Im nächsten Frame könnte ja was angekommen sein.

Screenshot aus meinem ersten Projekt

	Myn	Sa, Feb 11, 2012 15:01 Antworten mit Zitat
Ich denke das der Server nicht beim empfangen "hängen" bleibt sondern im nächsten Schritt, beim versenden an den Client. Wie kann ich den prüfen ob der Client nicht grade "gefreezt" ist, bzw. halt angehalten ?

Myn

Sa, Feb 11, 2012 15:01
Antworten mit Zitat

Ich denke das der Server nicht beim empfangen "hängen" bleibt sondern im nächsten Schritt, beim versenden an den Client.
Wie kann ich den prüfen ob der Client nicht grade "gefreezt" ist, bzw. halt angehalten ?

	Lion	Sa, Feb 11, 2012 18:25 Antworten mit Zitat
Soweit es mir bewusst ist, gar nicht. Das sollte aber auch beim Server überhaupt kein Problem sein, der Server schickts raus und dann ist es weg, an sich sollte der dann eher nichts mehr am Hut damit haben. Ohne Code ist es aber natürlich schwer, eventuell andere Fehlerquellen zu sehen.
Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

Lion

Sa, Feb 11, 2012 18:25
Antworten mit Zitat

Soweit es mir bewusst ist, gar nicht.
Das sollte aber auch beim Server überhaupt kein Problem sein, der Server schickts raus und dann ist es weg, an sich sollte der dann eher nichts mehr am Hut damit haben. Ohne Code ist es aber natürlich schwer, eventuell andere Fehlerquellen zu sehen.

Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb
Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb
AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

	Myn	Sa, Feb 11, 2012 19:00 Antworten mit Zitat
Fakt ist das wenn der Client "hängt" (Windowsfenster verschieben, in Fenstermodus wechseln etc.) ist auch der Server nach ein paar Sekunden gefreezt. Also KANN es nicht daran liegen das er darauf wartet das der Client Daten annimmt?

Myn

Sa, Feb 11, 2012 19:00
Antworten mit Zitat

Fakt ist das wenn der Client "hängt" (Windowsfenster verschieben, in Fenstermodus wechseln etc.) ist auch der
Server nach ein paar Sekunden gefreezt.

Also KANN es nicht daran liegen das er darauf wartet das der Client Daten annimmt?

	ZEVS	Sa, Feb 11, 2012 19:05 Antworten mit Zitat
Bei TCP: Ja. Wie soll man sonst sicherstellen, dass alles ankommt? Ich verweise gerne auf meinen ersten Post, um das Problem an seiner Ursache zu umgehen. ZEVS

ZEVS

Sa, Feb 11, 2012 19:05
Antworten mit Zitat

Bei TCP: Ja. Wie soll man sonst sicherstellen, dass alles ankommt?
Ich verweise gerne auf meinen ersten Post, um das Problem an seiner Ursache zu umgehen.

ZEVS

	Propellator	Sa, Feb 11, 2012 19:07 Antworten mit Zitat
Zitat: Dann musst du die beiden Programme nur noch z.B. über eine Datei kommunizieren lassen Mächtig schlechte Idee. Der Schreibzugriff auf die Festplatte ist nicht nur langsam, sondern auch unnötig. BlitzMax kann mit StandardIO einiges magisches hinzaubern, wieso nicht das? Ausserdem kann BlitzMax threading, keinen Grund für mehrere Prozesse. Hier ist ein Tipp: EVENT_TIMERTICK wird immer noch ausgesendet, auch wenn das Spielfenster rumgedragged wird. Siehe hier: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] GameWindow() Function GameWindow() Graphics 800, 600 timer:TTimer = CreateTimer(60) AddHook EmitEventHook, HandleEvents Local rot:Int = 0 While Not KeyHit(KEY_ESCAPE) PollEvent() rot :+ 1 SetRotation( rot ) DrawRect( 350, 250, 100, 100 ) Flip 1 Cls Wend EndFunction Function HandleEvents:Object( id, data:Object, context:Object ) Select TEvent(data).id Case EVENT_TIMERTICK Print MilliSecs() EndSelect EndFunction Eventuell kannst du somit den Netzwerkthread kontaktieren und ihm sagen, was los ist.
Propellator - Alles andere ist irrelephant. Elefanten sind die Könige der Antarktis.

Propellator

Sa, Feb 11, 2012 19:07
Antworten mit Zitat

Zitat:

Dann musst du die beiden Programme nur noch z.B. über eine Datei kommunizieren lassen

Mächtig schlechte Idee. Der Schreibzugriff auf die Festplatte ist nicht nur langsam, sondern auch unnötig. BlitzMax kann mit StandardIO einiges magisches hinzaubern, wieso nicht das? Ausserdem kann BlitzMax threading, keinen Grund für mehrere Prozesse.

Hier ist ein Tipp: EVENT_TIMERTICK wird immer noch ausgesendet, auch wenn das Spielfenster rumgedragged wird. Siehe hier:
BlitzMax: [AUSKLAPPEN]

GameWindow()

Function GameWindow()
	Graphics 800, 600
	timer:TTimer = CreateTimer(60)
	
	AddHook EmitEventHook, HandleEvents
	
	Local rot:Int = 0
	While Not KeyHit(KEY_ESCAPE)
		PollEvent()
		rot :+ 1
		SetRotation( rot )
		DrawRect( 350, 250, 100, 100 )
		Flip 1
		Cls
	Wend
EndFunction

Function HandleEvents:Object( id, data:Object, context:Object )
	Select TEvent(data).id
		Case EVENT_TIMERTICK
			Print MilliSecs()
	EndSelect
EndFunction

Eventuell kannst du somit den Netzwerkthread kontaktieren und ihm sagen, was los ist.

Propellator - Alles andere ist irrelephant.
Elefanten sind die Könige der Antarktis.

	Myn	Sa, Feb 11, 2012 19:22 Antworten mit Zitat
nach sowas hatte ich gesucht, jedoch läuft auch diese Geschichte nicht wieter wenn der X Button gedrückt wird, bzw gedrückt GEHALTEN wird. Gibt es da nicht irgend eine Möglichkeit das der Komplett ingnoriert wird?

Myn

Sa, Feb 11, 2012 19:22
Antworten mit Zitat

nach sowas hatte ich gesucht, jedoch läuft auch diese Geschichte nicht wieter wenn der X Button gedrückt wird,
bzw gedrückt GEHALTEN wird.

Gibt es da nicht irgend eine Möglichkeit das der Komplett ingnoriert wird?

	Propellator	Sa, Feb 11, 2012 19:27 Antworten mit Zitat
Wenn du einen separaten Thread fürs Netzwerk benutzt, kann dir der andere sowieso egal sein, EVENT_TIMERTICK kannst du auch benutzen um dort drin die Grafikoperationen zu vollziehen, oder wie gesagt, mit anderen Threads zu kommunizieren.
Propellator - Alles andere ist irrelephant. Elefanten sind die Könige der Antarktis.

Propellator

Sa, Feb 11, 2012 19:27
Antworten mit Zitat

Wenn du einen separaten Thread fürs Netzwerk benutzt, kann dir der andere sowieso egal sein, EVENT_TIMERTICK kannst du auch benutzen um dort drin die Grafikoperationen zu vollziehen, oder wie gesagt, mit anderen Threads zu kommunizieren.

Propellator - Alles andere ist irrelephant.
Elefanten sind die Könige der Antarktis.

	Myn	Sa, Feb 11, 2012 20:53 Antworten mit Zitat
Gibt es irgentwo ein gutes Tutorial etc zu Threads? Hab sowas noch nicht benutzt bisher.

Myn

Sa, Feb 11, 2012 20:53
Antworten mit Zitat

Gibt es irgentwo ein gutes Tutorial etc zu Threads?
Hab sowas noch nicht benutzt bisher.

	Myn	So, Feb 12, 2012 15:01 Antworten mit Zitat
Ich lasse nun einen Thread erstellen der alles was mit Netzwerk zu tun hat verwaltet. Mein Frage wäre jetzt wie ich diesen "drosseln" kann sodass er nicht 50%CPU verursacht ohne etwas zu tun?! ^^ (Dazu habe ich nichts gefunden )

Myn

So, Feb 12, 2012 15:01
Antworten mit Zitat

Ich lasse nun einen Thread erstellen der alles was mit Netzwerk zu tun hat verwaltet.
Mein Frage wäre jetzt wie ich diesen "drosseln" kann sodass er nicht 50%CPU verursacht ohne etwas
zu tun?! ^^ (Dazu habe ich nichts gefunden Surprised

)

	Propellator	So, Feb 12, 2012 17:29 Antworten mit Zitat
Mit einem Timer und WaitTimer, beispielsweise.
Propellator - Alles andere ist irrelephant. Elefanten sind die Könige der Antarktis.

Propellator

So, Feb 12, 2012 17:29
Antworten mit Zitat

Mit einem Timer und WaitTimer, beispielsweise.

Propellator - Alles andere ist irrelephant.
Elefanten sind die Könige der Antarktis.

	Myn	So, Feb 12, 2012 18:47 Antworten mit Zitat
Wenn ich das mache mache crasht das Programm, bzw. Keine Rückmeldung.

Myn

So, Feb 12, 2012 18:47
Antworten mit Zitat

Wenn ich das mache mache crasht das Programm, bzw. Keine Rückmeldung.

	BtbN	So, Feb 12, 2012 20:14 Antworten mit Zitat
Timer sind nicht Thread-fähig, die wo anders als im Hauptprogramm zu nutzen zerlegt alles.

BtbN

So, Feb 12, 2012 20:14
Antworten mit Zitat

Timer sind nicht Thread-fähig, die wo anders als im Hauptprogramm zu nutzen zerlegt alles.

	Thunder	So, Feb 12, 2012 21:24 Antworten mit Zitat
Benutze Delay dafür. Du kannst dir auf Basis von Delay und Millisecs auch selbst Timer bauen.

Thunder

So, Feb 12, 2012 21:24
Antworten mit Zitat

Benutze Delay dafür. Du kannst dir auf Basis von Delay und Millisecs auch selbst Timer bauen.

	BtbN	So, Feb 12, 2012 22:26 Antworten mit Zitat
Sollte im Thread doch garnicht nötig sein, er warte ja immer auf Daten, oder ist gerade am senden. Sehe nicht, wo da nen cpu-fresser auftauchen sollte.

BtbN

So, Feb 12, 2012 22:26
Antworten mit Zitat

Sollte im Thread doch garnicht nötig sein, er warte ja immer auf Daten, oder ist gerade am senden. Sehe nicht, wo da nen cpu-fresser auftauchen sollte.

	Myn	So, Feb 12, 2012 22:36 Antworten mit Zitat
Dann hab ich das falsch verstanden, wie kann ich denn einen bestehendem Thread wieder aufrufen? Oder ist der wieder weg wenn er seine aufgabe/ablauf ausgeführt hat?

Myn

So, Feb 12, 2012 22:36
Antworten mit Zitat

Dann hab ich das falsch verstanden, wie kann ich denn einen bestehendem Thread wieder aufrufen?
Oder ist der wieder weg wenn er seine aufgabe/ablauf ausgeführt hat?

Gehe zu Seite 1, 2 Weiter

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

Nach Oben

BlitzBasic Portal

Probleme mit TCP | Neue Frage

Betreff: Probleme mit TCP | Neue Frage