4. Protokollentwicklung

Protokollentwicklung

  • Z

    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)

    0
  • J

    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

    0
  • D

    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.

    0
  • Z

    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?

    0
  • J

    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

    0
  • D

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

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

    0
  • N

    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.

    0
  • J

    Klar doch (o;

    0
  • Z

    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.

    0
  • N

    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

    0
  • W

    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?

    0
  • W

    Habe soeben in der FAQ das Beispiel Progi zur Webcam gefunden.

    0
  • Z

    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

    0
  • W

    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.

    0
  • Z

    Die Lösung über den Timer hört sich Interessant an da man noch nen Slider einbauen kann wo man die geschwindigkeit regulieren kann. In einem event darf man ohnehin keine Schleife verwenden. Momentan habe ich das Problem das ich den FileStream global deklariert habe und ihn nicht freigeben kann. 😕 kein Plan wie ich die initialisierung des Filestreams ausserhalb des onRead Events machen soll und ihn wieder freizugeben. Perfekt wäre noch das für jede IP von der Dateien übertragen werden einen expliziten FileStream anzulegen. Ich habe beim Server eine TStringListe wo IP + Dateiname + Dateigröße von jedem Client gespeichert wird.
    Eine weitere StringListe speichert die übertragenen bytes und wird pro OnRead entsprechend hochgezählt um zu erkennen wann der File zu ende geladen ist um den Stream wieder freizugeben.

    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 ?

    0
  • W

    Hi Zero01,
    Ich hatte mit dem FileStream auch Probleme. Hatte es dann mal mit einem MemoryStream versucht und es hat geklappt.

    0
  • Z

    Ok, ich versuche es jetzt auch mal mit dem Memory Stream. Würdest du mir dabei helfen ?
    Bis jetzt habe ich folgendes:

    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

    0
  • J

    Debuggen und schauen wo genau der Abschuss passiert wär doch mal ne Option?

    -junix

    0
  • Z

    ich bekomme beim senden eine Acess violation at Address 000000000. Wenn ich das delete auskommentiere tritt dieser Fehler nicht ein, bin total ratlos 😕

    0
  • W

    Hm, wie esch scheint, haben wir wieder einmal das selbe Problem. Anfangs lief bei mir das Progi, also dass heisst einmal, und jetzt habe ich auch diesen Fehler, allerdings nicht immer bei der selben Adresse. Auch wenn ich das delete auskommentiere, tritt dieser Fehler manchmal auf.

    0
Anmelden zum Antworten