Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

Hi,

ich spiele mit dem Gedanken ein Chatprogramm zu programmieren.

Dabei soll es sich um einen Server handeln der die Nachrichten empfängt und

an alle Benutzer weiterleitet und um einen Client der beim Benutzer läuft, die

Nachrichten an den Server sendet und die Nachrichten der anderen Benutzer

vom Server empfängt und anzeigt.

Das ganze soll über Windows Sockets laufen.

Ich bin jetzt am Überlegen ob ich für das Senden und Empfangen jeweils einen

Thread anlege oder auch beides in einem möglich ist. Was würde z.B. passieren

wenn Server und Client gleichzeitig senden und sich alles in einem Thread befindet?

Würde ein anschließender recv() aufruf die Daten trotzdem einwandfrei empfangen?

Gruß

Guybrush

Geschrieben
Originally posted by Guybrush Threepwood

Hi,

Das ganze soll über Windows Sockets laufen.

Ich bin jetzt am Überlegen ob ich für das Senden und Empfangen jeweils einen

Thread anlege oder auch beides in einem möglich ist. Was würde z.B. passieren

wenn Server und Client gleichzeitig senden und sich alles in einem Thread befindet?

Würde ein anschließender recv() aufruf die Daten trotzdem einwandfrei empfangen?

Gruß

Guybrush

Ich würde es wie bei FTP machen, ein Port wird abgehört, wenn da was reinkommt wird dem Client mitgeteilt über welchen Port die zukünftige Kommunikation laufen soll und pro Verbindung ein Thread und ein dedizierter Port.

Frank

  • 2 Wochen später...
Geschrieben

Kann es eigentlich sein das Daten irgendwie untergehen wenn zuviele direkt

hintereinander über den selben Port gesendet werden?

Ich hab nämlich ne Funktion eingebaut das der Server sich die letzten 100

Nachrichten merkt und wenn jemand in den Chat eintritt, er diese 100 Nachrichten

gesendet bekommt. Nur komischerweise kommen die Nachrichten teils garnicht,

oder in verkehrter Reihenfolge an. Ich hab dann versucht nach jedem send()

ein Sleep() zu setzten, das hat aber auch nur ein bischen geholfen.

Hat irgendwer ne Idee woran das liegt?

Fehler treten nämlich auf beiden Seite nicht auf.:confused:

Geschrieben

Dann machst du selbst beim Empfangen oder Senden etwas falsch. Die eingebaute Fehlerkorrektur bei TCP sorgt dafür, dass nichts verloren geht und die Reihenfolge stimmt. Da es relativ schwierig ist, beim Senden etwas falsch zu machen ;), tippe ich mal darauf, dass beim Emfang was nicht stimmt.

Geschrieben

ich wüßte nicht was falsch sein könnte, im Client hab ich in einen 2.Thread eine

Schleife in der folgendes recv() sitzt:

recv(CliSocket,szText,501,0);

und im Server hab ich halt für jede Verbindung einen Thread mit Schleife

wo folgendermaßen gesendet wird:

send(ChatSocket[nPort],szText,strlen(szText)+1,MSG_DONTROUTE)

Geschrieben

Es gibt keine 1-zu-1-Beziehung zwischen send und recv, das sind reine Byteströme.

Dein recv wird AFAIK erst dann zurückkommen, wenn die 501 Bytes voll sind. Natürlich können dann mehrere Strings drinstehen. Und der letzte String im Puffer ist mit ziemlicher Sicherheit nicht vollständig.

Geschrieben

Das ist bei mir aber nicht so:confused:

Wenn der Client gestartet wird, sendet er einen String mit dem Namen und dem

Passwort des benutzers an den Server, dieser String ist ca. 10- 20 Byte lang.

Der Server erwartet einen max. 100 Byte String und macht trotzdem weiter.

Danach wird nämlich der String mit einer Textdatei verglichen und dann ein freier

Port gesucht.

Geschrieben
Originally posted by Guybrush Threepwood

Das ist bei mir aber nicht so:confused:

Stimmt, weiß auch nicht, wie ich darauf gekommen bin. Ich hatte irgendwie in Erinnerung, dass recv blockt, bis der Puffer voll ist. War wohl nun ein Traum...
Geschrieben

Hallo,

recv() blockiert solange, bis Daten auf dem Socket anliegen. Diese Daten werden dann (bis zur maximalen Länge) gelesen und zurückgeliefert. Optional kannst Du den Socket noch auf nonblocking schalten; in dem Fall kehrt recv() auch dann zurück, wenn keine Daten anliegen.

Nic

Geschrieben

Hallo,

Verloren gehen können die Daten eigentlich nur, wenn Du UDP verwendest. TCP hat eine Flußkontrolle. Entweder beim Empfang geht etwas schief, oder Du fragst beim Senden die Returnwerte nicht richtig ab (d.h. Du bekommst es nicht mit, wenn das Senden fehlschlägt, weil beispielsweise ein Puffer beim Empfänger voll gelaufen ist).

Nic

Geschrieben

Also ich frage bei jedem send bzw. recv ab ob der Returnwert gleich

SOCKET_ERROR ist und wenn ja lass ich mir eine Fehlermeldung samt Fehlercode

ausgeben. Es tritt aber nirgendwo ein Fehler auf.

Ich habe mir jetzt mal alles ausgeben lassen was der Server sendet, um zu

sehen ob vielleicht ein Logikfehler drinsteckt, es wird aber alles gesendet.

Als ich dann beim Client eine Messagebox eingebaut habe die mir immer

das anzeigt was von recv geholt wurde, kahmen nur noch ca. 6 Nachrichten

von ca. 40 an.

Das bestätigt doch den Verdacht das zu viel gesendet wird das zu langsam

vom socket geholt wird, oder nicht?

Geschrieben

Hab`s gerade überprüft und er liefert mehr Zeichen zurück. Du hattest

also Recht damit, dass mehrere Nullterminierte Strings zurückgeliefert werden.

Nur wie komme ich da am besten dran? Funktionen wie strtok() stoppen ja beim

'\0'. Muss ich mir da selber was schreiben, oder gibst da doch irgendeine

Funktion?

Geschrieben

Soweit ich weiß, gibt es da keine Funktion. Entweder suchst du nach dem Nullzeichen weiter, falls noch nicht alle empfangenen Bytes verarbeitet wurden, oder du nimmst ein anderes Trennzeichen.

Oder du entwickest ein eigenes "Protokoll", mit einem Header, in dem steht, wie lang der nachfolgende String ist. Dann brauchst du gar kein Trennzeichen mehr.

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...