solved(??): c#: datenpakete >1kb senden/empfangen
URL: https://www.overclockers.at/coding-stuff/solved_c_datenpakete_gt1kb_senden_empfangen_73276/page_1 - zur Vollversion wechseln!
Jedi schrieb am 31.03.2003 um 13:11
netzwerkspezialisten hergehört
folgendes problem:
es gibt ein programm zum versenden/empfangen von dateien über netzwerke.
lokal auf dem rechner läuft der transfer problemlos.
wenns aber darum geht, dateien über netze zu schicken, müssen diese erst auf 1kb große segmente gesplittet werden.
realisiert ist das ganze unter c#.
irgenwelche ideen?
atrox schrieb am 31.03.2003 um 17:25
und wie hast du es realisiert ? udp? oder mußt du auch aus anderen gründen auf die MTU im Ethernet rücksicht nehmen ? (zb weil die firewall/nat keine fragmentierung zulassen)
Yeahman schrieb am 31.03.2003 um 18:33
Interessant wäre auch was nicht geht. Kommen die Packete nicht an, oder fehlerhaft, ...
watchout schrieb am 31.03.2003 um 18:51
netzwerkspezialisten hergehört
folgendes problem:
es gibt ein programm zum versenden/empfangen von dateien über netzwerke.
lokal auf dem rechner läuft der transfer problemlos.
wenns aber darum geht, dateien über netze zu schicken, müssen diese erst auf 1kb große segmente gesplittet werden.
realisiert ist das ganze unter c#.
irgenwelche ideen?
rofl - geile fragestellung
(scnr)
Jedi schrieb am 31.03.2003 um 22:46
*arg*
das kommt dabei raus, wenn ma zuviel gleichzeitig macht 
ok, nochmal und jetzt hoffentlich verständlicher:
senden von datenpaketen geht nur bis maximal 1kb, da sonst der empfänger eine invalid package-fehlermeldung (oder so in der richtung) bekommt. (bin grad ned am entsprechenden rechner).
leider sollen auch größere dateien (>1kb) geschickt werden können und das aufsplitten und zusammensetzen (am zielrechner) braucht unnötige rechenleistung.
merkwürdig an der ganzen sache ist, dass lokal (also sender und empfängerprog auf einem rechner) alles wunderbar geht. übers netzwerk gibts eben oben beschriebenes problem.
hatte schon wer a ähnliches problem oder eine ahnung, was das problem sein könnte?
watchout schrieb am 31.03.2003 um 23:58
*arg*
das kommt dabei raus, wenn ma zuviel gleichzeitig macht
ok, nochmal und jetzt hoffentlich verständlicher:
senden von datenpaketen geht nur bis maximal 1kb, da sonst der empfänger eine invalid package-fehlermeldung (oder so in der richtung) bekommt. (bin grad ned am entsprechenden rechner).
leider sollen auch größere dateien (>1kb) geschickt werden können und das aufsplitten und zusammensetzen (am zielrechner) braucht unnötige rechenleistung.
merkwürdig an der ganzen sache ist, dass lokal (also sender und empfängerprog auf einem rechner) alles wunderbar geht. übers netzwerk gibts eben oben beschriebenes problem.
hatte schon wer a ähnliches problem oder eine ahnung, was das problem sein könnte?
und mit welchem protokoll verschickst du's?
schonmal probiert an andere rechner zu schicken?
atrox schrieb am 01.04.2003 um 00:40
http://www.ethereal.com/download.html
downloaden und nachschauen, was am traffic wirklich nicht hinhaut.
FMFlash schrieb am 01.04.2003 um 14:53
senden von datenpaketen geht nur bis maximal 1kb, da sonst der empfänger eine invalid package-fehlermeldung (oder so in der richtung) bekommt. (bin grad ned am entsprechenden rechner).
leider sollen auch größere dateien (>1kb) geschickt werden können und das aufsplitten und zusammensetzen (am zielrechner) braucht unnötige rechenleistung.
merkwürdig an der ganzen sache ist, dass lokal (also sender und empfängerprog auf einem rechner) alles wunderbar geht. übers netzwerk gibts eben oben beschriebenes problem.
hatte schon wer a ähnliches problem oder eine ahnung, was das problem sein könnte?
ich hatte schon ein ähnliches problem, allerdings gings dabei um unerklärliche programmfehler bei zu großer (ca >10kb) paketgröße. aus bequemlichkeit hab ichs dann - weils ohnehin nicht auf effizienz in sachen übertragungsgeschwindigkeit ankam - auf 1kb/paket belassen.
allerdings wirst du kein glück haben wenn du eine 1 mb große datei mit einem paket schicken willst, aus dem einfachen grund das die maximale paketgröße eines IP pakets 64kb beträgt.
es wird dir nichts anderes übrig bleiben als die zu verschickende datei stück für stück zu lesen, zu schicken, zu lesen ... usw, während die zielanwendung zur gleichen zeit empfängt, schreibt, empfängt, ... so lange bis die sendende anwendung signalisiert das das ende der datei erreicht und die übertragung abgeschlossen wurde.
atrox schrieb am 01.04.2003 um 16:36
bleibt die frage: warum nicht tcp? da brauchst du dich ums aufteilen, sequenzieren, bestätigen, zusammensetzen usw gar nicht mehr kümmern.
that schrieb am 01.04.2003 um 19:16
allerdings wirst du kein glück haben wenn du eine 1 mb große datei mit einem paket schicken willst, aus dem einfachen grund das die maximale paketgröße eines IP pakets 64kb beträgt.
Das wird sowieso vom Betriebssystem aufgeteilt, bei Ethernet z.B. auf ca. 1,5 kB Stücke.
atrox schrieb am 01.04.2003 um 19:26
bevor wir weiterspekulieren, sollte uns unser Jedi-Ritter mal über das verwendete Protokoll aufklären. (evt wäre auch ein code-stück interessant)
bei tcp braucht man sich zb überhaupt keine gedanken machen, bei udp nur über die maximale IP-datagram größe. zusätzliche constrains wie die Ethernet MTU kommen nur in bestimmten fällen hinzu. erst bei RAW-Sockets muß man große Rücksicht auf die Netzwerkinfrastruktur nehmen.
vielleicht ist es was vollkommen anderes ?
Jedi schrieb am 03.04.2003 um 18:57
verschickt wird über sockets (tcp/ip)
wenn der server daten an client weiter leitet, bekommt der 1. client die daten korrekt, der 2. jedoch nicht ....
es dürfte jedoch am servercode liegen.
es wär schon toll, wenn zumindest 5kb segmente verschickt werden könnten, denn dadurch wär die performance schon mal einiges höher.
atrox schrieb am 03.04.2003 um 19:21
nachdem tcp-sockets stream orientiert sind, sollten blockgrößen eigentlich nicht von belang sein. der fehler ist also sehr wahrscheinlich in einem der beiden programme an den endpunkten der verbindung.
btw.. was meinst du mit 1ter & 2ter client?
FMFlash schrieb am 04.04.2003 um 01:41
ich nehme an er meint multiple verbindungen auf einem tcp socket 
in dem bereich ist tcp imho nicht mehr sehr praktisch zu handhaben, da bevorzuge ich persönlich doch udp.
@atrox: es ist (leider) sehr wohl von belang wie groß die teilstücke des files sind die man auf einmal verschickt (fehlerhafter code?).
könntest du vielleicht code von einem selbst gebauten file transfer bei dem die teilgröße keine rolle spielt posten? dann wüsste ich wenigstens was ich damals falsch gemacht hab und das problem vom jedi würde sich vielleicht auch lösen 
atrox schrieb am 04.04.2003 um 02:29
Vorschriftsschreiber?
das hat er aber leider nicht erwähnt. ob die design-entscheidung vorteilhaft ist/war läßt sich ohne kenntnis des umfeldes nicht beurteilen.
es ist (leider) sehr wohl von belang wie groß die teilstücke des files sind die man auf einmal verschickt (fehlerhafter code?).
für den socket ist es egal, das program muß es halt richtig auseinandernehmen bzw zusammensetzen, aber das hab ich eh schon geschrieben. bei tcp kann der sender die daten in blöcken zu n bytes übergeben, und der empfänger zu m bytes lesen, ohne daß irgendeine spezielle beziehung zwischen n und m herschen muß.
aber ich bin mir nicht sicher, ob jedi tatsächlich reine tcp-streams verwendet, er schreibt was von "invalid packet"-fehlermeldungen, etwas daß tcp auf user-seite eigentlich gar nicht kennt.
hab jedi schon mal gebeten, die entscheidenden code stellen zu posten - auch wenn ich kein c# experte bin, ließe sich überprüfen, obs am blocking liegt, oder wo anders.
hier ist zb ein c# tcp sample code:
http://www.c-sharpcorner.com/Networ...ramPart2RVS.asp
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025