Jump to content

tacitus

Members
  • Gesamte Inhalte

    12
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von tacitus

  1. tacitus

    Tftp

    danke euch beiden, klappt enun einwandfrei ...
  2. tacitus

    Tftp

    Hi zusammen, ich möchte gern ein TFTP daemon server unter XP installieren, habe aber Null - Ahnung wie ich das machen soll (1) Wo bekomme ich so ein Ding kostenfrei auf dem Netz ? (2) Wie muss ich das Ding installieren ? Jede Hilfe wäre echt willkommen .....
  3. Hallo blub, da scheine ich ja an einen echten Meister geraten zu sein. Ich gebe durchaus zu, dass TCP/IP Neuland für mich ist. Ich denke, ein solches Forum ist eine sehr gute Plattform dieses Neuland zu entdecken, da kannst Du Dir also solche post sparen .. ciao mark
  4. Natürlich habe ich nichts gegen Füllbytes, wenn sie Sinn machen. Es erscheint mir nur ein wenig unlogisch, warum das oben beschriebene Problem überhaupt auftritt. Ich sende weniger und es "knallt" ... ich sende erheblich mehr Daten und es funktioniert. Dabei sind beide Varianten Ethernet-(ISO) Konform und unterscheiden sich nur durch die Datengrösse ciao mark
  5. ... soweit ich das sehe, ist die Mindenstgrösse der TCP Nuztdaten immer 64Byte. Wenn die Anzahl der Nutzdaten unterhalb dieser Grösse liegt füllt das Protokoll automatisch auf ciao
  6. ... folgendes Problem Ich sende gleichzeitig Bilddaten ( 32000 Bytes ) via UDP und Steuerbefehle ( x Bytes ) via TCP über ein und den selben Port. Mein Server ist ein Embedded PC unter VxWorks und mein Client ist ein normaler PC unter WXp. Wenn die Grösse meines TCP Steuerbefehls nahe an der MSS liegt, so klappt alles ohne Probleme. Der TCP Befehl besteht dann aus 52 Nutzbytes und 1413 Schrottbytes. Wenn ich nun nur die 52 Nutzbytes senden möchte ( ich habe dann inc Header mehr als 64 Bytes ) so verliere ich UDP Fragmente und ich bekomme ICMP Fehlerprotokolle "Zeitüberschreitung beim Datagramm". Meine Java-Konsole hängt sich dann auf, nach ca. 30-60 sek. fängt sie dann wieder an um sich dann immer mal wieder zyklisch aufzuhängen. Erhöhe ich die Anzahl der Schrottbytes dann wieder, z.B. auf 192 ( (int) 48 ), so gehts dann wieder ... Hat jemand von euch so etwas schon einmal beobachtet .... ich will keine Schrottbytes senden... ciao mark
  7. tacitus

    Tcp/ip Ii

    Hallo zusammen, erneute eine Frage bzg. TCP/IP ( ... fast noch Neuland für mich ) Ich schicke irgendeinen Befehl von meinem Client ( XP, Java ) an meinen Server ( C++, MPC823 ). Ich schaue mir mittels Etereal die Reaktionszeiten an. Nun kommt es, aus mir bislang unerklärlichen Gründen, vor, dass der Server den Befehl recht schnell entgegennimmt, er aber erst im 100 us-Bereich ( Microsekunde ) das ACK an den Client zurücksendet. Das gleiche lässt sich auch umgekehrt beobachten, also wenn ich vom Server an der Client sendet. Meine Frage nun. Habe ich irgendwelche Möglichkeiten beim TCP Protokoll auf die ACK Zeiten Einfluss zu nehmen oder sind die darunterliegenden Schichten dafür verantwortlich ? Client und Server sind direkt via Hub miteinander verbunden, also kein LAN/WAN ciao
  8. tacitus

    Tcp/ip

    .... warum ich das überhaupt machen will ich schicke ein Frame vom Client via TCP mit Nutzdaten unterhalb der MSS Grösse( 1456 Bytes ). Ethereal Messungen zeigen mir, dass das anschliessende TCP-ACK vom Client mit ca. 150 ms delay kommt. Nun schicke ich einen Frame mit mehr als MSS Nutzdaten ( also z.B. 1464 Bytes ). Dieser wir natürlich in zwei Frames zerlegt ( einer mit 1406 Bytes, der zweite mit 4 Bytes ). Etereal misst das anschliessende TCP-ACK im us Bereich. Die Idee nun ist die, dass MSS auf meine Datenmenge anzupassen um das TCP-ACK schneller zu bekommen ( NUR EINE IDEE, dass kann auch absoluter Quatsch sein ) Der eigentliche Grund jedoch liegt darin, dass ich Bilddaten via UDP über Ethernet verschicken möchte .... dies mit bestmöglicher Qualität, also maximaler Bildwiederholfrequenz. Nebenbei müssen noch ein paar TCP Steuerpackete verschickt werden. Wenn jetzt irgendwelche TCP-ACK Frames unendlich lange warten, so verringert sich zwangsläufig meine Bildwiederholfrequenz, also meine Qualität. Es ist noch wichtig zu sagen, dass ich nicht über ein LAN gehe. Client und Server hängen direkt via HUB zusammen. ... danke für die wirklich gute Reaktion ...
  9. tacitus

    Tcp/ip

    Hallo ... ist es möglich, die MSS ( Maximum Segment Size ) bei TCP Protokollen ( default 1420 Bytes ) zu beeinflussen ) ciao
  10. danke auch, wird sofort ausprobiert ...
  11. Hallo zusammen Ich suche einen möglichst kostenlosen Port-Sniffer. Ich möchte gezielt an meinem XP-Client schauen können, ob meine UDP und TCP Pakete richtig von meinem VxWorks Server ankommen. Schoen wäre es auch, wenn ich an einem bel. Port eine Performanceanalyse machen könnte. Wer kann mir da einen Hinweis geben ? Ciao
  12. ... mmm, bin mir nicht sicher ob ich hier richtig bin ... ich versuche gerade via embedded Server-PC ( MPC823/VxWorks ) via UDP Protokoll einem Java-Client unter XP Bilddaten zu schicken. Server sendet, Client läuft in Timeout. Ein parallele TCP-Kommunikation funktioniert. Darf ich für beide Protokolle den gleichen Port nutzen. Hat da irgenwer eine Idee ?
×
×
  • Neu erstellen...