Protokollentwicklung
-
Ich versende die Daten von einem ClientSocket an einen ServerSocket. Wenn ich das richtig verstanden habe, ist das Protokoll, das die beiden verwenden IP v. 4, oder? unabhängig von dem was ich mache. Bei IP v.4 kann die maximale Paket grösse 65'535 Byte betragen. Also muss doch der ClientSocket den ganzen Stream in Pakete aufteilen, welche dann an den Server gesendet werden, da TCP/IP auf Datagram basiert, ist nicht garantiert, dass die Pakete in der richtigen Reihenfolge ankommen. Beim ServerSocket wird ja bei jedem ankommenden Paket ein OnReadClient Event ausgelöst, oder? Also muss ich nun die Pakte, falls sie einen unterschliedlichen Weg genommen haben und deshalb nicht mehr in der richtigen Reihenfolge angekommen sind, wieder richtig zusammensetzten.
-
wedmer schrieb:
da TCP/IP auf Datagram basiert, ist nicht garantiert, dass die Pakete in der richtigen Reihenfolge ankommen.
nö, aber das regelt tcp schon selber. musste dir keine gedanken drum machen. deiner anwendung gehen keine daten verloren (es sei denn die verbindung bricht ab) und es wird auch nix vertauscht. ist fast so zuverlässig wie das speichern auf'n datenträger
-
Ich hab das gleiche Problem wie du Wedmer !
Hab schon etwas vorgegriffen und werde meinen Code dies Nacht posten wenn ich etwas weiter gemacht habe. Das Empfangen hakelt bei mir noch da ich keine while Schleife zum empfangen in einem Event verwenden darf. Wenn du willst können wir das Problem zusammen lösen.David
Edit: wie kommst du drauf das TCP ein Datagramm ist ? das ist IP und UDP
-
nö, aber das regelt tcp schon selber
das würde ja bedeuten, dass der ClientSocket meinen Stream von sagen wir 10MB auf die einzelnen Pakete aufteilt, die anschliessend auf den Weg schickt, der ServerSocket die Pakete wieder in der richtigen Reihenfolge zusammensetzt und erst dann den OnClientSocketRead Event auslöst? tuts aber nicht.
@Zero01 ja können wir gerne versuchen.
wie kommst du drauf das TCP ein Datagramm ist ? das ist IP und UDP
meines wissen gibt es die Paket und die Leitungsvermittlung. Bei der Paketvermittlung wird weiter in Datagramme und Virtual Circuit unterteilt und ich dachte immer TCP/IP auf dem prinzip der Datagramme funktioniert, sprich die Pakete können via unterschiedliche Wege zum Ziel gelangen.
-
Um die Reihenfolge kümmert sich TCP, bei UDP müsste man sich einen Mechanismus zurechtbasteln der die Pakete nach der Reihenfolge sortiert und zusammen setzt.
Ich hoffe ich komme Heute Nacht weiter, bis später.........David
-
wedmer schrieb:
nö, aber das regelt tcp schon selber
das würde ja bedeuten, dass der ClientSocket meinen Stream von sagen wir 10MB auf die einzelnen Pakete aufteilt, die anschliessend auf den Weg schickt, der ServerSocket die Pakete wieder in der richtigen Reihenfolge zusammensetzt und erst dann den OnClientSocketRead Event auslöst? tuts aber nicht.
musses aber. das ganze internet verlässt sich drauf. bestimmt machste irgendwas falsch mit dem socket. man muss z.b. immer die rückgabewerte der send()- und recv()-funktionen beachten
-
Bis jetzt hab ich folgendes:
Senden
char buf[1024]; int c,b; TFileStream *out = new TFileStream(Form1->OpenDialog1->FileName, fmOpenRead); out->Seek(0,soFromBeginning); Form3->Label4->Caption = "Uploading..."; do { b = out->Read(buf,sizeof(buf)); c = Form1->ClientSocket1->Socket->SendBuf(buf,b); while(c == -1) { c = Form1->ClientSocket1->Socket->SendBuf(buf,b); } } while(b == sizeof(buf)); delete out;void __fastcall TForm1::FileTransfer1Click(TObject *Sender) { int i; int Size,lenght; char Buff[1024]; if (OpenDialog1->Execute()) { String dateipfad = OpenDialog1->FileName; String dateiname; //--------Datei größe HANDLE file; int size; file = CreateFile(dateipfad.c_str(), GENERIC_READ, NULL, NULL, OPEN_EXISTING, NULL, NULL); size = GetFileSize(file, NULL); CloseHandle(file); Form3->Label6->Caption = size; i = OpenDialog1->FileName.LastDelimiter("\\"); Form3->Label3->Caption = dateipfad.SubString(i + 1,dateipfad.Length()); dateiname = dateipfad.SubString(i + 1,dateipfad.Length()); String query = "File:"+ dateiname + ":" + String(size); strcpy(Buff,query.c_str()); Size = sizeof(Buff); lenght = strlen(Buff); AuthUDP1->RemoteHost = remote_ip; AuthUDP1->SendBuffer(Buff,Size,lenght); Form3->Show(); } }Das Empfangen klappt leider noch nicht 100%
(Poste ich später)
-
Ouch... Ich seh da schon was:
1. diese while sendefehler... da könnte man a) eine do..while draus machen, zweitens baust du dir da im dümmsten Fall ne endlosschleife, wenn was mit dem Socket krumm läuft...
2. Net hat recht. TCP sorgt selber für die Numerierung und das Zusammensetzen der Pakete... Da brauchste keinen Mechanismus für. Bei UDP hingegen schon. Nur ist es witzlos UDP zu nehmen, wenn man nachher eh alle Pakete braucht. UDP macht dann sinn, wenn die Wichtigkeit, dass das Packet angekommen ist nicht wirklich hoch ist -> Onlinegames
Dann brauchste auch nur nen schnellen Mechanismus der sich merkt welches die letzte Paketnummer war und alle die eintrudeln und eine tiefere Nummer haben verwirft.
-junix
-
junix schrieb:
UDP macht dann sinn, wenn die Wichtigkeit, dass das Packet angekommen ist nicht wirklich hoch ist -> Onlinegames
Naja, so stimmt das nicht ganz.
Weil wenn meim spielen (online) ein Paket fehlt, kommts zu diesen Lags.Wird UDP auch nicht für Dinge verwendet die verbindungslos sein sollen?
Beispiel:
Counterstrike, wenn du da LAN Server suchen willst (und im Lan gibts kein Masterserver), wird doch immer nen UDP Paket versendet und aktive Server antworten drauf. So das man schnell IP's von Server hat.
-
Jop, TCP ist verbindungsorientiert und UDP verbindungslos.
Online Spiele leben von UDP, das ist definitiv sicher.
Ja, im LAN werden via Broadcast Server ermittelt.Wie kommt ihr darauf einen Filetransfer auf UDP aufzubauen wenn man TCP zur Verfügung hat ? Das schreit ja förmlich danach
Ich informiere jediglich den Empfänger über UDP das eine Datei mit der Größe X von User X hochgeladen werden soll und nach Bestätigung öffne ich die TCP Verbindung zum Empfänger. Also wird UDP als reine Authentifizierung und Steuerung verwendet. Interessant wäre jetzt einen Mechanismus auszutüfteln wie man von mehrenen Clients Dateien empfangen kann
Momentan hab ich ne StringListe wo IP und Filename + Filesize drin stehen, man müsste es nur hinbekommen das für jeden File ein expliziter Filestream geöffnet wird und wenn die Empfangenen Bytes >= der Filesize sind wird er freigegeben. Hat jemand ne bessere Idee ? Multithreading?
-
UDP: Ja aber bei UDP erfolgt doch auch kein Acknowledge oder? KLar kommt es zu lags... aber wenn bei 1000 Paketen / s 1 verloren geht ist das nicht die Welt.
Äh apropos Mechanismus wo jeder das zu empfangen hat: War da nicht was mit der Broadcast-Adresse die man sich aus der Netzmaske ausrechnen kann?
-junix
-
junix schrieb:
Äh apropos Mechanismus wo jeder das zu empfangen hat: War da nicht was mit der Broadcast-Adresse die man sich aus der Netzmaske ausrechnen kann?
-junixJa das Stimmt. Broadcast gehen aber nur im LAN (wenn ein Router,Switch das nicht filtert), im Internet wird das gefiltert.
-
DJ BlackEagle schrieb:
Broadcast gehen aber nur im LAN (wenn ein Router,Switch das nicht filtert), im Internet wird das gefiltert.
wär ja auch übel wenn broadcasts durchkämen. dann könnte jeder popelige teilnehmer das internet lahmlegen.
-
Klar doch (o;
-
junix schrieb:
UDP: Ja aber bei UDP erfolgt doch auch kein Acknowledge oder? KLar kommt es zu lags... aber wenn bei 1000 Paketen / s 1 verloren geht ist das nicht die Welt.
Äh apropos Mechanismus wo jeder das zu empfangen hat: War da nicht was mit der Broadcast-Adresse die man sich aus der Netzmaske ausrechnen kann?
-junix
Nein, mir geht es um einen Datei Transfer wo ein Server von mehreren anderen Clients gleichzeitig ein File annehmen können.
-
Zero01 schrieb:
Nein, mir geht es um einen Datei Transfer wo ein Server von mehreren anderen Clients gleichzeitig ein File annehmen können.
das geht auch. jeder teilnehmer kann eine vielzahl von verbindungen quasi-parallel bedienen. für dateitransfer würde ich aber immer tcp und nicht udp nehmen
-
So habs nun auch geschaft die Dateien erfolgreich zu versenden und empfangen. Mein ursprüngliches Problem war, dass ich wärend einer langweiligen Vorlesung programmiert habe und um das ganze zu testen, mit meinem PC zuhause kommuniziert hatte und meine Firewall verrückt spielte, weiss zwar nicht wieso, aber ist eh ein scheiss Ding. Ich habe es nun so gelösst, dass ich zuerst vom Client aus die Grösse der Datei als String an den Server sende, dann am Client mitteile, dass dieser bereit ist und lese anschliessend die Daten ein.
@Zero01 hast du das mit dem empfangen nun auch hin gekriegt? Ich habe im Post von dir über neues Fenster zur Laufzeit erstellen gelesen, dass dein Chat Progi ein Webcam Support besitzt. Nun wollte ich dich noch fragen, wie du die Bilder der Webcam ausliest?
-
Habe soeben in der FAQ das Beispiel Progi zur Webcam gefunden.
-
Jop ,hab gestern Nacht Filme mit 800 Mb und mehr vom Rechner zum Laptop gesendet.
Ich habe das Problem das beim Client sowie Server die CPU Auslastung auf 100% springt und alles bis auf den File Transfer blockiert wird. Ich bastel noch etwas und poste den code später@ Net:
Zero01 schrieb:
Wie kommt ihr darauf einen Filetransfer auf UDP aufzubauen wenn man TCP zur Verfügung hat ? Das schreit ja förmlich danach

Ich würde mich hüten mit UDP Dateien zu versenden. ich benutze UDP für den Chat und zur Steuerung des Client/Server Sockets

Beispiel: FTP Port 20 Authent und Control und Port 21 Daten
-
Hatte das gleiche Problem wie du Zero01. Beim Server, welcher die Daten empfängt, konnte ich es einfach lösen indem ich. Ich hatte eine Schleife in der er gefangen war, bis er alle Daten erhalten hatte. Habe jetzt die nötigen Variabeln in der Klasse als Privat deklariert und die Schleife herausgenommen, jetzt wird die Funktion OnClientRead einfach mehrmals aufgerufen, bis er alle Daten hat und speichert das File anschliessend ab. Bei Client, welcher die Datei sendet habe ich es noch nicht gelösst. Wenn ich etwas Zeit habe werde ich es mal mit einem Timer versuchen, damit ich ihn nicht in der Schleife hangen lasse, bis alles raus ist.