[GELÖST] String an Programm senden ohne Verbinden

  • VB.NET

Es gibt 18 Antworten in diesem Thema. Der letzte Beitrag () ist von Padmak.

    [GELÖST] String an Programm senden ohne Verbinden

    Hallo,
    Äh das hört sich jetzt dämlich an aber ich weiß nicht wie ich es genauer sagen soll^^
    Ich probiere es mal:
    Ich habe ein Programm mit dem man die Online-PCs in der Arbeitsgruppe anzeigen lassen kann.
    Per doppelklick darauf werden die freigegebenen Ordner dieses PCs geöffnet
    Ich würde gerne per Rechtsklick darauf eine Nachricht verschicken lassen
    Grundgerüst ist fertig
    Problem: Es funktioniert nur wenn sich die Programme verbinden
    Das will ich aber vermeiden
    Ich will dass das Programm einfach mal die Textnachricht schickt und aber gleichzeitig horcht ob etwas reinkommt
    Ist das möglich?
    Bitte KEINE ganzen Codebeispiele, nur kurze Vorschläge und stupser in die Richtung :)

    Grüße,

    Padmak

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

    Ich meine:
    Programm wird auf Computer A und Computer B gestartet
    Das Programm A schickt eine Nachricht an Computer B
    Computer B horcht einfach nur, ob etwas hereinkommt
    Sobald etwas hereinkommt, zeigt er eine Messagebox mit dem gesendeten Text

    Aber das ganze ohne dass sich die Programme groß verbinden müssen
    Beispielcode habe ich von hier, aber das ist genau das was ich nicht will:
    [VB.NET] Simples, funktionierendes Beispiel einer TCP/IP-Verbindung zwischen zwei Rechnern.

    Vielleicht könnt ihr mir jetzt helfen ;)

    Padmak

    Naja ich dachte es mir ohne einen zentralen Server...
    das wäre viel flexibler...
    Das Programm müsste nur einfach immer horchen auf einen bestimmten Port
    Ich weiß leider nicht wie das in VB2008 realisiere...
    In AutoIt startet man einfach den TCP-Dienst und dann wird auf eingehende Verbindungen/Nachrichten gehorcht
    geht das hier auch irgendwie?

    Padmak

    Wie du in dem von dir gelinktem Sourcecode sehen kannst connected sich der Server auf irgendeine IP, das egal, wichtig ist der Port und dort wird ständig der Network Stream eingelesen.

    Aber dein Client der was schicken soll, natürlich benötigt der eine Adresse wohin er etwas schicken soll und somit haste wieder Client und Server, was daran unflexibel? Bzw. wie stellst du dir das vor, etwas zu schicken ohne eine Angabe von Adresse?

    Hallo,

    es gibt ja noch die möglichkeit von PeerToPeer, dabei hat man jetzt keinen direkten Server, jeder PC ist mit jedem verbunden...jedoch weiß ich nicht, warum man keine "normale" Verbindung mit einem Server aufbauen sollte, evtl. möchte er, dass im lokalen Netzwerk der Server autom. erkannt wird?! Ebenso wie für's Internet würde ich dafür DynDns(oder einen eigenen Server mit fester Adresse) empfehlen...

    Mfg jvbsl
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Ich verstehe immer noch nicht wie du dir das vorstellst. Bei einer Verbindung von A nach B muss immer einer horchen (den Server stellen) und der andere sich mit diesem Verbinden (Client). Ohne das funktioniert es nicht. Dieses schreckliche AutoIt macht nichts anderes als ein Socket zu erstellen und auf eingehende Verbindungen zu warten, das was du "nicht willst".

    Naja vielleicht hab ich auch irgendwas falsch verstanden...

    Die IP bekomme ich ja über den PC-Namen oder?
    Kurze Erklärung zum Programm:
    Es listet per "net view" alle Online-PCs im lokalen Netzwerk auf (in einer Listbox)
    Per doppelklick auf einen PC werden die freigegebenen Ordner dieses PCs aufgelistet
    Also kann ich doch darüber die lokale IP herausfinden oder?
    Und an diese IP würde ich die Nachricht dann schicken...

    Ich vermute mal dass ich das ganze von wegen verbinden falsch verstehe...
    Ich weiß nicht ob sich die Programme auch kurzzeitig verbinden können...
    Kann mir das nochmal wer kurz erklären?^^
    (KEIN Code^^)

    Padmak

    Edit: Oder zumindest nicht nuur Code^^
    vor allem nicht der ganze^^
    Will ja auch was lernen ;)

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

    Das UDP verbindungslos ist, ist mit bewusst. Nur ergibt der Einsatz des UDP Protokolls hier keinen Sinn, bzw. würde einen erheblichen Mehraufwand bedeuten. Alleine dafür zu garantieren, dass alles in richtiger Reihenfolge und vor allem vollständig empfangen wird. Aus diesen Gründen habe ich UDP logischerweise schon als Lösung gestrichen.

    beate schrieb:

    Aus diesen Gründen habe ich UDP logischerweise schon als Lösung gestrichen.


    Hmm... gerade wollte ich mich für den tollen Tipp bedanken :D
    Aber du hast mich zum nachdenken gebracht...
    Es funktioniert echt gut.. Ich bin gerade am Formatieren der Nachrichten (Etwa "An: *PCNAME* Von: *ABSENDERPCNAME* Text: *TEXT*")
    Scheint super zu laufen...
    Ist das alles nur schein oder sind das Probleme die man vernachlässigen kann?^^
    Auf jeden Fall ein herzliches DANKE an picoflop :)

    Padmak

    picoflop schrieb:

    beate schrieb:

    Alleine dafür zu garantieren, dass alles in richtiger Reihenfolge und vor allem vollständig empfangen wird.

    Wozu so viel Aufwand. Es sind kleine Datenmengen und im lokalen Netz. UDP ist da das Protokoll der Wahl.

    Weil UDP nicht garantiert, dass die Daten in der richtigen Reihenfolge bzw. überhaupt ankommen. Für eine stabile Kommunikation bei der keine Pakete verloren gehen sollen ist TCP das Mittel der Wahl.

    beate schrieb:

    Weil UDP nicht garantiert, dass die Daten in der richtigen Reihenfolge bzw. überhaupt ankommen.

    OK, das ist die (mir ebenfalls bekannte) Theorie. Und in der Praxis? Wie oft kommen im LAN UDP Pakete mit einer Größe unter 1k nicht oder in der falschen Reihenfolge an? TCP dürfte da viel fehleranfälliger sein, bzw erfordert deutlich mehr "Prüfaufwand" (Verbindung besteht noch, muss resetet werden, ...?)

    picoflop schrieb:

    beate schrieb:

    Weil UDP nicht garantiert, dass die Daten in der richtigen Reihenfolge bzw. überhaupt ankommen.

    OK, das ist die (mir ebenfalls bekannte) Theorie. Und in der Praxis? Wie oft kommen im LAN UDP Pakete mit einer Größe unter 1k nicht oder in der falschen Reihenfolge an? TCP dürfte da viel fehleranfälliger sein, bzw erfordert deutlich mehr "Prüfaufwand" (Verbindung besteht noch, muss resetet werden, ...?)


    TCP ist da nicht fehleranfälliger, es garantiert ja schließlich den korrekten Empfang, auch wird der Prüfungsaufwand von dem Betriebssystem erledigt. Außerdem darf man nie von etwas ausgehen wenn es nicht garantiert ist, vielleicht funktioniert es ja nur genau gerade bei einer speziellen Infrastruktur. Was ist z.B. mit WLAN oder einer möglichen Erweiterung des Programms? Und was, falls es wo anders, z.B. in größeren Netzwerken oder dem Internet, eingesetzt werden soll? Natürlich kann man genau so gut UDP einsetzen, ich nehme es hier gerade wohl sehr genau, nur sollte man auch die Nachteile dieses Protokolls beachten. In einem Punkt hat UDP einen großen Vorteil, der Verbindungsaufbau bei TCP dauert sehr lange und entfällt bei UDP ja. Dann muss halt nur ein einfacher Bestätigungsmechanismus für die Nachrichten implementiert werden.

    Okayokay ich habs mittlerweile verstanden :D
    Das Primärproblem ist schon gelöst :)
    Es funktioniert einwandfrei
    @beate: Sobald ichs übers Internet laufen lasse (macht keinen Sinn im Internet die Online-PCs abzufragen^^) melde ich mich bei dir wegen TCP^^
    Atm reicht mein UDP auf jeden Fall :)
    Also Danke nochmal an alle, ich denke ich markiere es mal als Gelöst (vorrausgesetzt so ne Funktion gibts hier^^)

    Padmak

Facebook
Telefonspende