-junix

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

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.

David

@net

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

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)

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

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.

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?

Ä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

Ä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

Ja das Stimmt. Broadcast gehen aber nur im LAN (wenn ein Router,Switch das nicht filtert), im Internet wird das gefiltert.

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.

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.

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

@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?

@ 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

Weiß da jemand Rat wie das zu realisieren ist oder bin ich auf dem richtigen Weg

Aber die Sache mit dem globalen Deklarieren und nicht mehr freigeben können nervt total, da muss es doch ne andere Möglichkeit geben wie man explizit für jede Client IP einen Filestream vor dem Senden anlegt und danch wieder freigibt ?

Global:
TMemoryStream * Stream = new TMemoryStream();

Senden

TMemoryStream *mem = new TMemoryStream();
  mem->LoadFromFile(Form1->OpenDialog1->FileName);
  mem->Seek(0,0);
  Form1->ClientSocket1->Socket->SendStream(mem);
  delete mem;

Empfangen OnReadEvent

int Buffer = 1024;
  int filesize = StrToInt(FileSize(filelist->Values[Socket->RemoteAddress]));
  String filename = FileName(filelist->Values[Socket->RemoteAddress]);

  BYTE *Buffer_BYTEp = new BYTE[Buffer];
  Stream->Position = Stream->Size;

  Socket->ReceiveBuf(Buffer_BYTEp, Buffer);
  Stream->Write(Buffer_BYTEp, Buffer);

  delete [] Buffer_BYTEp;

  if (Stream->Size == filesize)
  {
   Stream->SaveToFile(Form2->Label1->Caption + "\\" + filename);
   delete Stream;
  }

Wie hast du das Empfangen gelöst ? Momentan wird das Programm so übel abgeschossen das man noch nicht mal mehr ne Fehlerausgabe hat
So wie es aussieht steigt er schon beim Senden aus

-junix