@Toni03 Löse zunächst das Problem, eine Datei über TCP zu verschicken, gugst Du z.B. hier.
Wenn das klappt, eröffnest Du einen Thread, wo beide laufenden Lösungen (Chat und Dateitransfer) miteinander verheiratet werden.

Toni03 schrieb:

Ich weiß ja nicht wie ich Dateien schicke

Hast du dir den Link von Rod angeschaut und verstanden?
Zu deinem fertigen (?) Chat, ist das eine 1:1 Kopie von kevins TCP Multichat oder hast du dir etwas eigenes gebaut?

Wenn wir dir hier helfen sollen musst du und schon etwas entgegenkommen und uns zeigen das du etwas in Eigenregie versucht, ob es nun falsch ist oder nicht, dafür sind wir dann da um dich auf den richtigen Weg zu bringen und Fehler auszumerzen.
Willst du hingegen servierfertigen Sourcecode musst du dein Anliegen im Marktplatz Posten und eine gewisse Gegenleistung erbringen.

Also für deinen nächsten Post würde ich dir Empfehlen:
-Dein jetzigen Quellcode (bitte im VB.NET Tag)
-Eine konkrete Fehlerbeschreibung ("Es funzt nicht, habe schon gegooglet...") zählt nicht, unsere Glaskugeln sind gerade in der Reinigung.
-Eine korrekt gestellte Frage mit den von uns benötigten Infos

EDIT: Du hast ja schonmal ein Thema dazu aufgemacht und Recht gute Antworten erhalten..
denkst du jetzt wenn du genug nervt bekommst du fertigen Sourcecode? ich hoffe das ist nicht deine Absicht
Ip-Chat Dateien Schicken

Arbeitest du mit der TcpClient-Klasse oder direkt 'nem Socket? (Ansonsten gibt's beim TcpClient die Client-Eigenschaft welche das Socket liefert).

Entwickle dir ein kleines Protokoll.
Ich schätze mal im Moment sendest du einfach nur die Strings über's Netzwerk.
Schick noch ein Byte vornedran, welches aussagt, was für eine Art von Nachricht gerade kommt. Z.B. 0x01 -> Normale Chat Nachricht, 0x02 -> Datei.

Beim Empfangen liest du ein Byte, und anhand dessen weißt du was in der Nachricht kommt. Bei 0x01 liest du wie vorher auch deine Chat Nachricht.
Bei 0x02 liest du die Datei.
Dabei würde ich eine simple Struktur erstellen.
Zuerst schickst du den Dateinamen.
Dann die Länge der Datei in Bytes,
und danach blockweise die Bytes.

Und genau so empfängst du's alles auch wieder.

Toni03 schrieb:

Ich habe jetzt nochmal lange gegooglet

Warum guckst du nicht einfach mal auf vb-paradise?
TcpKommunikation + Networkstream
Das deckt so einiges ab: Broadcast-Kommunikation, peer2peer, call&response, FileTransfer, nur Encryption sollte man iwie anners aufziehen.

Problem: Ist nicht so einfacher Stoff - aber was hilfts? Das Problem ist nicht einfach, daher die Lösung auch nicht. Also entweder lernst du das nötige Handwerkszeug, oder es geht halt nicht.

Toni03 schrieb:

Ich habe bisher nur einen TCP Chat gemacht

Und wie hast du das angestellt? Ich gehe mal davon aus, dass du die Daten (den Text) in ein Byte Array konvertiert hast und denn dann über einen NetworkStream in die etablierte TCP Verbindung geschrieben hast.

Toni03 schrieb:

ch weiß ja nicht wie ich Dateien schicke

Im Prinzip das selbe:
1.) Datei aus dem FileSystem auslesen
2.) In ein Byte Array umwandeln
3.) über die TCP Verbindung verschicken
4.) Auf der Gegenseite die Daten wieder zusammenbauen
5.) Byte Array wieder ins FileSystem schreiben

Toni03 schrieb:

ich habe keine Ahnung wie

Du wiederholst dich

Lg Radinator

Schau auch notfalls mal hier vorbei: SkrivaPrisma 8 - TCP Chat

Grüße
Vainamo

Radinator schrieb:

Im Prinzip das selbe:
1.) Datei aus dem FileSystem auslesen
2.) In ein Byte Array umwandeln
3.) über die TCP Verbindung verschicken
4.) Auf der Gegenseite die Daten wieder zusammenbauen
5.) Byte Array wieder ins FileSystem schreiben

Das würde ich nicht als Stand der Technik bezeichnen.
Vorrausgesetzt eine Verbindung über TcpClient-Objekte, gehts so:

1. Datei aus dem FileStream in den NetworkStream schaufeln - und das wars auch schon auf der Sende-Seite
   
2. Daten aus dem Networkstream in den FileStream schreiben - und das wars auch schon auf der Empfänger-Seite
   

Natürlich steckt der Teufel im Detail - aber da gehen wir beide mal großzügig drüber weg.

Ok ich geb zu, der weg von mir ist jetzt recht speziell (bei Bildern und Textnachrichten hab ich das bisher so gemacht - bin zwar drauf gebracht worden, dass man ein BitMap auch direkt in den Stream schreiben kann, aber das ist jetzt mal ohne Belang) bzw nicht mehr "state of the art", aber ich geh mal davon aus, dass der TE noch in der Lage ist, es nach meiner Anleitung zu lösen.

@EDR: Du hast es halt allgemein formuliert, ich hingegen EINEN Weg, wie man es machen kann.
Ich gehe mal davon aus, wir sind uns beide einig, dass die Datei Packet weise verschickt werden muss

LG Radinator

Radinator schrieb:

Ich gehe mal davon aus, wir sind uns beide einig, dass die Datei Packet weise verschickt werden muss

nö - und das ist eben der Punkt.
Wir brauchen nur den Networkstream, und das mit den Paketen ist überhaupt nicht unsere Baustelle.
Sondern das machen die TCPClient-Objekte an den beiden Enden einer Verbindung unter sich aus - ganz ohne unser Zutun.

Dem TE ging es ja aber auch nicht darum zu erfahren, wie er dieTCP Verbindung aufbaut, sondern, wie er die Daten verschicken kann

@EDR: TCP segmentiert nur die verschiedenen Pakete für simulatene TCP Verbindungen mit unterschiedlichen EndPoints, mehr nicht. EIne Segmentierung für alles andere ist für fast alles andere was nicht gerade nen Echo-Server/Client ist von nöten und somit sehr wohl Relevant. Wie das ganze dann jedoch implementiert/abstrahiert wird ist wiederum eine andere Sache.
Aber da hier steht TCP Chat, ist es eindeutig nötig zu segmentieren.

jvbsl schrieb:

TCP segmentiert nur die verschiedenen Pakete für simulatene TCP Verbindungen mit unterschiedlichen EndPoints, mehr nicht

Nanu? Ich dachte, alle Kommunikation zw. Endpunkten im INet, ob nu unterschiedlich oder nicht, laufe immer in Paketen ab, die simultan verschickt werden.
Und die Leistung von Tcp ist nu grad, dieses Kuddelmuddel zuverlässig zu organisieren.
Weil ich halte mich da vollkommen raus - wie gesagt: ich lese/schreibe auf den Networkstreams, und das Segmentieren in Pakete überlasse ich den darunterliegenden Schichten.
Tatsächlich ist mir sogar egal, ob da überhaupt paketiert wird oder nicht, hauptsache im Empfänger-Netwokstream kommt genau das wieder raus, was ich im Sender-Networkstrem reingeschrieben habe.

Allerdings muss auch ich den Datenstrom in Abschnitte unterteilen, weil iwie müssen ja verschiedene Nachrichten auseinandergehalten werden, und Amfang und Ende haben. Aber das hat nichts mit Paketen zu tun.

Eine simplere Art ist die Datei in ein Base64-String zu konventieren, dann bei dem Empfänger den Base64-String in ein Byte-Array zu verwandeln und dann direkt in einer Datei zu schreiben.

Natürlich laufen die in Paketen ab, es wird auch segmentiert, jedoch wirst du für so ziemlich alles andere nochmal extra Segmentieren müssen, jedoch nimmt man dafür meist Paketgröße > 1500. Und es geht dabei darum den selben EndPoint simultan für unterschiedliche Datenströme verwenden zu können.

Edit: @EDR: jetzt weiß ich vlt. was du meintest, natürlich machen UDP und ko dasselbe^^

@Davaxyr: Einfacher schneller und schöner ist es die Länge einfach vorweg zu senden. Base64 ist nur für reine Textprotokolle gedacht und Textprotokolle ansich sind in den meisten fällen schon eine dämliche Idee.

jvbsl schrieb:

jedoch wirst du für so ziemlich alles andere nochmal extra Segmentieren müssen, jedoch nimmt man dafür meist Paketgröße > 1500.

Ich sags nochmal: Für einen Chat muss ich garnix in Pakete segmentieren - niemals! - wenn ich TcpClient - Objekte verwende.
Diese Arbeit wird mir restlos abgenommen.

ErfinderDesRades schrieb:

Und die Leistung von Tcp ist nu grad, dieses Kuddelmuddel zuverlässig zu organisieren.

Die Leistung von TCP ist es, ein [...]zuverlässiges, verbindungsorientiertes Protokoll [...] zu sein (Wikipedia). Heißt nix anderse, als dass es TCP ermöglicht zu garantieren, dass die Daten auch ankommen (Re-transmission, wenn das Packet nicht ankommt). Mit dem "in der richtiten Reihenfolge" ist nur so halbwahr: Wenn etwa die Pakete in der Reihenfolge 1,2,3,4,5,5 abgeschickt werden und sie in der Reihenfolge 1,2,4,5,6,3 ankommen - weil etwa Packet 3 einen etwas längere Route genommen hat - dann sorgt TCP nur dafür, dass sie beim abschicken nummeriert werden und beim Empfangen in der richtigen Reihenfolge aus dem Networkstream gelesen werden.

ErfinderDesRades schrieb:

ich lese/schreibe auf den Networkstreams

Mal angenommen du willst über eine TCP Verbindung eine Musikdatei verschicken. Wie genau stellst du das in .NET an? (Sprache ist mir jetzt erst mal egal - kann sowohl C# als auch VB.NET sein :D)

jvbsl schrieb:

jedoch nimmt man dafür meist Paketgröße > 1500

Das mit den 1500 ist nur die "Fenstergröße", also die Menge an Bytes, die der (Nutzdaten-)Inhalt eines TCP Packet initial hat (=Maximum Transmission Unit, MTU). Je nachdem, ob die nächsten (ich glaub es waren 4) Übertragungen erfolgreich sind, wird die MTU halt dann hochgesetzt (um den Faktor *2 - wenn ich mich recht erinnere). Sollte die Leistung der Verbindung abnehmen, wird sie halt wieder runter gesetzt. Wichtig: MTU besagt nur, wie groß der Container ist, in welchem die Nutzdaten abgelegt werden, es kann auch sein, dass ich eine MTU von 1500 Bytes habe, aber nur 2048 Bytes übertrage. Der Rest ist halt dann leer.

Lg Radinator

Radinator schrieb:

Mal angenommen du willst über eine TCP Verbindung eine Musikdatei verschicken. Wie genau stellst du das in .NET an?

Aber das habe ich doch nu zig mal gesagt - ich kann nicht recht fassen, wie schwer verständlich das zu sein scheint:
Im Sender lese ich sie aus einem FileStream aus und schreib sie in den Networkstream - im Empfänger lese ich sie aus dem Networkstream, und schreib sie in einen Filestream.
Kein Paket nirgends.

WAS du machst, hab ich verstanden - meine Frage ist WIE du das anstellst.

Bitte erst meine Aussage lesen, verstehen und dann erst antworten

Radinator schrieb:

Wie genau stellst du das in .NET an?

Lg Radinator