Ip-Chat Dateien Schicken

  • VB.NET

Es gibt 17 Antworten in diesem Thema. Der letzte Beitrag () ist von ~blaze~.

    Ip-Chat Dateien Schicken

    Hey Leute ich würde gerne wissen wie man mit einem IP Chat Dateien schicken kann. Möglichst alles nur in einer Form

    *Topic verschoben*
    if Brain.Enabled = False Then
    Process.start("C:\Brain.exe")
    End if
    __________________________________________________

    Error: Brain.exe not found System shut down

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Dazu müssten wir wissen, wie dein "IP-Chat" bisher aussieht.

    Grundlegend brauch man in seinem "Protokoll" einen "Header" der die Anwendung darauf hinweißt, dass nun ein Text, eine Datei, oder was auch immer ankommt. Nach auslesen des Headers muss dann entsprechend des Typs der Nachricht weiter verfahren werden.

    Toni03 schrieb:

    Möglichst alles nur in einer Form
    Auch Sender und Empfänger?
    Ich dachte, der Empfänger sitzt an einem anderen Rechner.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ja es ist alles in einer Form und läuft ohne Probleme

    Vollzitat entfernt. ~Thunderbolt
    Dateien
    • Chat.zip

      (250,89 kB, 124 mal heruntergeladen, zuletzt: )
    if Brain.Enabled = False Then
    Process.start("C:\Brain.exe")
    End if
    __________________________________________________

    Error: Brain.exe not found System shut down

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Thunderbolt“ ()

    Der generelle Ansatz wäre hier, die Datei byteweise einzulesen und dann in Paketen zu verschicken. Diese Pakete fügt der Empfänger dann wieder zusammen und schreibt das ganze byteweise zurück in eine Datei. Du musst dir halt nur überlegen, wie du in einem Protokoll festlegt, wie der Empfänger weiß, welches Paket er hat und was er damit anstellen soll.
    Wenn du mehr Fragen dazu hast, melde dich ruhig bei mir, ich habe mittlerweile viel Erfahrung in Bezug auf TCP Chats.

    Grüße
    Väinämö
    Hmm - wenn man mit TCP arbeitet, muss man eiglich nicht mit Paketen herum-fuchteln - das übernimmt eiglich die TCP-Schicht.
    Also wenn man TcpListener und TcpClient benutzt, ist man dem Hickhack mit den Datenpaketen doch entronnen.

    Aber Option Strict On sollte man machen, und den Deppen-Namespace rauswerfen.
    Sonst arbeitet vb.net ja garnet als eine objektorientierte Sprache.

    Vainamo V schrieb:


    Wenn du mehr Fragen dazu hast, melde dich ruhig bei mir, ich habe mittlerweile viel Erfahrung in Bezug auf TCP Chats.


    Das ganze tat ich ja auch und sie antworteten nicht. @ErfinderDesRades Das Werde ich machen.
    if Brain.Enabled = False Then
    Process.start("C:\Brain.exe")
    End if
    __________________________________________________

    Error: Brain.exe not found System shut down

    Toni03 schrieb:

    und sie antworteten nicht
    Keiner auf dem Board wird dir hier ein Strick aus dem, im Internet allgemein akzeptierten, du drehen ;) Des weiteren sind wir hier in einem Forum, Antworten, selbst "persönliche" können sich u.U. verzögern. Ne höhere Antwortchance hat man eben, wenn man seine konkreten Fragen für alle sichtbar postet ^^

    Um sich komplett von Bits'n'Bytes, Streams, oder Sockets und sonstigem zu verabschieden würde ich einfach nochmal ne andere Technologie in den Raum werfen:
    WCF :
    codeproject.com/Articles/29485/WCF-for-Beginners
    codeproject.com/articles/78660…indows-service-simplified
    codeproject.com/articles/65349…ting-with-windows-service
    Duplex WCF:
    c-sharpcorner.com/uploadfile/d…le-duplex-service-in-wcf/
    codeproject.com/Articles/49184…nners-Guide-to-Duplex-WCF

    Um es kurz zu fassen, mit WCF rufst du Funktionen auf einem Server auf der diese Funktionen dann ausführt. Alles darunter wird vollautomatisch von WCF verarbeitet. Darüber hinaus hat WCF die Möglichkeit sich als RESTful Service zu verhalten, sodass alles was HTTP kann, auch mit dem Service kommunizieren kann.

    Duplex WCF bringt die Sache noch ein Stück weiter, sodass ein Server Code auf einem verbundenen Client ausführen kann.
    Es braucht etwas Einarbeitung um mit der Konfiguration zurecht zu kommen, doch man wird hinterher damit belohnt, dass man eben Funktionen aufruft, anstatt sich mit der gesamten Schicht darunter zu plagen.

    Toni03 schrieb:

    Das ganze tat ich ja auch und sie antworteten nicht.
    Stimmt, da ich deinen Code nicht einsehen könnte. Ich lade generell keine Dateien von Mediafire oder sonstigem. Das hatte ich auch in der Konversation geantwortet, allerdings wurde die Antwort (warum auch immer) nicht versendet. Jetzt konnte ich mir hier deinen Code ansehen, dann kann ich dir auch "intensiver" helfen.

    ~blaze~ schrieb:

    Daher die Unterteilung in Pakete, schätze ich.
    Genau, die Pakete dienen der Performance und ermöglichen zudem eine Übersicht über den Transfer, da man so einen Fortschrittsbalken o.ä. anzeigen kann.

    Grüße
    Väinämö
    Das mit Paketen und Performance müsste man mal überprüfen. Übersicht über den Transfer hat man bei Streams aber doch auch - oder kann man sich zumindest verschaffen, etwa indem man die Bytes mit-zählt, die man raus-schaufelt.
    Ich hab gehört, die Logik mit Paketen sei vertrackt, die kommen in falscher Reihenfolge an, manche sind beschädigt, und müssen nochmal neu angefordert werden, und so Spässe. Das wären so Sachen, die ich gerne der Tcp-Protokoll-Schicht überlasse.



    @EaranMaleasi - Frage zu Wcf:
    Etwa für einen richtigen Chat braucht man zweierlei Kommunikations-Modelle: Zum einen nach dem Observer-Pattern, also dass ein Sender sendet, und wer will kann die Sendungen abonnieren, oder auch wieder abbestellen.
    Das andere Kommunikations-Modell wäre Call-and-Response, also ich frage was an, und bekomme eine Antwort.
    Wie ich Wcf bislang kennen gelernt hab, unterstützt es nur Call-And-Response - was du halt sagst, man kann da Methoden auf der Gegenseite aufrufen (wobei man aber mit den Argumenten aufpassen muss, dass da im Hintergrund nicht voll der overcrowded Traffic abgeht).
    Auch das mit den Rückgabewerten scheint mir eine Farce, denn da hängt sich die Anwendung ja auf, wenn aufgrund der INet-Verbindung der Return-Value sich verspätet.
    Also muss man eh alles asynchron gestalten, und dann kann man das mit den Return-Values auch bleiben lassen.

    So habichs jdfs. in Erinnerung: Zunächstmal der "Boah - super geil!" - Effekt, aber dann kamen lauter Einschränkungen, Haken und Ösen, was man besser nicht macht, was man auch wissen muss etc., dass ich am Ende eiglich keine Erleichterung mehr fund gegenüber einer gut gebastelten NetworkStream-Architektur.

    Sorry - ist bischen her, dass ich mich damit rumgeärgert habe, daher meine Argumentation recht schwammig, aber vlt. kannste was dazu sagen?

    ~blaze~ schrieb:

    dass TCP keine mehrfachen Verbindungen vom gleichen Endpunkt aus zulässt. Ist das nicht so?
    Ja, aber man kann die zweite Verbindung für die Dateien ja auch auf einem anderen Port laufen lassen, das funktioniert nämlich sehr wohl.

    Grüße
    Väinämö
    Ich hoff', das kam nicht als Provokation rüber, es war eine ernst gemeinte Frage. Das mit den Ports wusste ich, das wird ja von einigen Programmen so gemacht.
    Man müsste dann halt für jeden Nachrichtenkanal einen weiteren Port öffnen, ich weiß nicht, ob das so geschickt ist. Ich denk', ich würde da vielleicht wirklich einfach das andere System umsetzen, zumal der TCP-Header eh recht groß ist im Vergleich zu dem, was effektiv nötig ist. Wenn die Payload dann möglichst vollständig genutzt wird, ist das Verhältnis zwischen Payload und Header halt am besten.
    Das würde ich allerdings in einem späteren Schritt erst optimieren, wenn es nicht gerade darum geht, ein Framework für diesen Zweck zu implementieren.

    Viele Grüße
    ~blaze~

    ~blaze~ schrieb:

    Ich hoff', das kam nicht als Provokation rüber
    Keine Angst, kam es nicht ;) .

    Ein normales TCP Paket hat einen Header von (32 Bit x 5 = 160 / 8 =) 20 Bytes. Wenn man sich z.B. entscheidet, die Dateien in Paketen á 1024 Bytes zu verschicken, liegt das Overhead-Payload Verhältnis bei 1:51,2. Das lässt sich imho noch verkraften. Sicherlich ist aber sinnvoller, wenn man den Payload effektiv nutzt und die Datei gleich komplett verschickt. Denn da die Übertragung über eine seperate Verbindung stattfindet, dürfte bei optimaler Asynchronisierung/Threading die normale Kommunikation nicht beeinflusst werden.

    Natürlich lässt sich das ganze noch weiter optimieren, wenn man berücksichtigt, dass ein TCP Paket (in der Regel) eine MSS von 1452 Bytes hat, könnte man die Daten in 1452 Byte große Pakete aufteilen und den Payload somit zu 100% nutzen (Vergleich: Bei Paketen á 1024 Bytes werden nur ~71% genutzt.)


    ErfinderDesRades schrieb:

    So habichs jdfs. in Erinnerung: Zunächstmal der "Boah - super geil!" - Effekt, aber dann kamen lauter Einschränkungen, Haken und Ösen, was man besser nicht macht, was man auch wissen muss etc., dass ich am Ende eiglich keine Erleichterung mehr fund gegenüber einer gut gebastelten NetworkStream-Architektur.
    Stimmt, WCF scheint zwar super praktisch, ist aber im Endeffekt nie wirklich genau das was man haben will, zumal es "relativ" unflexibel in der Handhabung ist.

    Grüße
    Väinämö
    Bei einem Chat liegt die durchschnittliche Nachrichtenlänge vermutlich schon weit unter 500 Bytes. Man will auch nicht warten, bis die Payload vollständig ausgefüllt ist, da sonst die Nachrichtenverzögerung zu hoch wäre und ggf. sogar Teile einer Nachricht erst später ankommen. Ich bin da häufig lieber etwas sparsamer, selbst wenn ich eine halbe Stunde in etwas investieren muss. Bzw. ich passe zumindest die Architektur so an, dass es mit geringem Aufwand nachträglich eingebaut werden kann. Das ist ja im allgemeinen nicht mit so einem großen Aufwand verbunden, wenn man sich vorher Gedanken gemacht hat.

    Ich denke, dass das jetzt eher vom eigentlichen Thema wegführt.

    Viele Grüße
    ~blaze~