Multiplexer für 2 Programme übers Modem

Am 06.06.2008, 12:11 Uhr, schrieb je :

Hä? Also nochmal langsam zum Mitschreiben: Du hast irgendwo ein Gerät, das Daten per serieller Schnittstelle+Modem verschicken kann. Auf der anderen Seite steht ein Win-Rechner, der ebenfalls ein Modem an einer seriellen Schnittstelle hat und diese Daten empfängt. Was ist jetzt genau mit dem noch zu bestimmenden Programm P1? Das soll dieselben Daten erhalten, oder wie? Falls dem so ist, würde ich versuchen, einfach nur die ankommenden RX-Daten auf eine zweite serielle Schnittstelle zu legen - das müsste ein RS232-Treiber normalerweise verkraften. Dann hättest Du die Daten dort nochmal zur Verfügung, könntest aber nicht unbedingt etwas senden. Oder willst Du ein Modem an Ethernet anschließen? Das ist aber schon eher exotisch. Aber vielleicht kannst Du den geplanten Aufbau nochmal genauer skizzieren. Mir ist nicht klar, was da von wo nach wo soll.

Wie weit stehen denn die Gerätschaften eigentlich auseinander? In Ethernet-Reichweite oder doch eher viele km? Je nach Entfernung könnte auch RS485 eine Lösung sein... da kann man mehrere Geräte an einen Bus hängen...

Ansgar

Hallo Ansgar,

siehe unten.

Ger=E4t, Programm(e) Modem-W=E4hlverbindung (nach alter Zeit, sprich 56k), also die ganze Infrastruktur, ja.

Genau. Aber der Datenaustausch ist bidirektional. Auf dem Win-Rechner w=E4hlt man sich ein (das unterst=FCtzt P2) und betreibt Fernwartung f=FCr das Ger=E4t (nennen wir halt noch G2).

Nein, gar nicht. Die Daten haben nichts miteinander zu tun, sollen aber durch die selbe Telefonleitung mit derselben Modem-W=E4hlverbindung gequ=E4lt werden. Und zwar so, dass P2 von D1, G1, P1 usw nichts mitbekommt und so funktioniert, als ob die X1 nicht vorhanden w=E4ren. Nat=FCrlich wird die =DCbertragungsgeschwindigkeit langsamer, aber das nehmen wir in kauf.

Ja, ich will an den gemeinsamen Ethernet-Anschluss (nach dem Serial2Ethernet-Konverter f=FCr G2 ein Modem anschlie=DFen, dass die normale Telefonleitung benutzt. An der Infrastruktur (analoger Telefonanschluss) kann ich n=E4mlich nichts =E4ndern. Wobei ich festgestellt habe, dass so ein Modem garnicht TCP/IP-Modem genannt wird. Das ist doch dann eher ein DSL-Modem, oder? Wobei ich mir nicht sicher bin, ob man das einfach so zwischen Ethernet-Anschluss und analoger Telefonleitung nutzen kann, ohne DSL angemeldet zu haben. Und dass ich dazu DSL verlange, kann ich auch nicht bringen. Vielleicht sollte ich das Modem "56k-Modem mit Ethernet-Anschluss" nennen.

Alternativ w=E4re vielleicht noch, dass wir statt dem Ethernet-Anschluss an G2 auch eine serielle Schnittstelle anbieten, diese dann mit der anderen bei G1 irgendwie multiplexen, und dann wieder an der PC-Stelle demultiplexen. Ist aber m.E. ziemlich unsch=F6n und wird wohl nie funktionieren, weil man da sicher auf sich selbst angewiesen ist. Ethernet/TCP/IP hat halt den Vorteil, dass man die unterschiedlichen Pakete immer anhand der IP-Adresse identifizieren kann.

Ist sehr unterschiedlich, aber es k=F6nnen durchaus 1000km und mehr sein. Es gibt auch viele Standorte, wo G1e und G2e stehen (immer paarweise), die auch in Deutschland verstreut sind. PCs (die andere Seite) gibt es weniger.

Johannes

Am 06.06.2008, 13:57 Uhr, schrieb je :

OK, sowas gibt bzw. gab es. Microlink 56K LAN von Devolo, oder so. Nur als Beispiel. Soweit so gut.

Was Du aber in dem Fall brauchst, ist eine gewisse Änderung der Infrastruktur. Bisher unterhalten sich ja Deine Anwendung und das entfernte Gerät so, als wären sie einfach per seriellem Kabel miteinander verbunden - nur halt mit Modems dazwischen und Verbindungsaufbau durch Deine Anwendung. Das geht aber bei Deinem Vorhaben nicht mehr so ohne weiteres. Denn Du müsstest, soweit ich das sehe, über die Modemstrecke ja jetzt Netzwerkverkehr schicken. Ist kein prinzipielles Problem und geht sogar mit Windows-Bordmitteln, allerdings verwaltet dann nicht mehr Deine Anwendung den Verbindungsaufbau, sondern Windows, per DFÜ-Netzwerk (hachja, das waren noch Zeiten... d.h. indirekt wäre es dann schon eine Anwendung, die eben die Verbindung anfordert, weil sie Daten für's andere Ende hat...).

Du müsstest auf der PC-Seite ein herkömmliches serielles Modem benutzen und den Windows-RAS-Server aktivieren (im DFÜ-Netzwerk). Auf der entfernten Geräteseite das LAN-fähige Modem so einstellen, dass es bei Anruf einen Rückruf zu Deiner Telefonnummer macht (sonst könnte ja jeder kommen!) und sich dort per PPP-Protokoll einloggt. Es müsste Modems geben, die sich so konfigurieren lassen. Dann hast Du eine Netzwerkverbindung über die Modemstrecke, mit PPP und TCP/IP. So, jetzt ist also die direkte serielle Schnittstelle vom DFÜ-Netzwerk belegt. Um Deine Anwendung (die ja wohl nur seriell "spricht"), mit der ganzen Geschichte zu verheiraten, brauchst Du entweder eine Software auf dem PC, die entweder a) eine virtuelle serielle Schnittstelle bietet und hintenraus die Daten per TCP/IP versendet, oder aber b) Du benutzt eine zweite physikalische serielle Schnittstelle, hängst dort Deinen Hardware-Seriell-zu-LAN-Adapter dran und stellst den PC so ein, dass er zwischen seinem LAN-Interface und der Modem-PPP-Verbindung alles durchroutet. Das ist notwendig, sonst geht's gar nicht. Win98 und Konsorten kann das übrigens nicht vernünftig. Mit Win2K und XP geht das besser, da kann man das Routing/Bridging konfigurieren.

Zusammenfassend also: Der entscheidende Unterschied ist, dass Du auf der Modemstrecke statt wie bisher rein die Abbildung einer seriellen Schnittstelle nunmehr ein Netzwerkprotokoll (mit seriellem Unterbau, also PPP oder SLIP) betreiben musst.

Keine Ahnung, was es aktuell noch für LAN-fähige Analogmodems am Markt gibt... ist in Zeiten von DSL jedenfalls eine aussterbende Spezies...

Ansgar

Es sind Geräte und (Protokoll)Programme am Markt , mit denen die Fernprogramierung bzw die Fernbedienung für SPSen wie z.B. Siemens S5 realisiert wird. Ich würd mich mal drüber informieren. Diese Funktioniern auch über VPN im WEB. Vorsicht Bei Modems wird die Kopplung zeitlich überwacht. Damit die Verbindung nicht abbricht übertragen die Modems Prüfttelegramme zueinander , wenn längere Zeit nichts gesendet wird. Ob DSL oder Ethernet das mit den Pausen mitmacht ?

Bei Seriellen Kopplungen kann ich aus Erfahrung nur sagen Du musst alles bis in letzte Detail klären um sicher zu sein das es Funktioniert.

Gruße vom Rhein H.L

je schrieb:

Ohne viel Basteleien d=FCrfte ein zweiter Telefonanschlu=DF die eleganteste L=F6sung zu sein, z.B. in Form von ISDN, einer kleinen Telefonanlage und zwei Modems.

Ja, aber nur die schon bestehende Applikation P2. Bei der anderen Applikation P1 sind wir (noch) frei, w=FCrden aber gerne auf Ethernet/ TCP/IP gehen.

Das geht aber bei Deinem Vorhaben nicht mehr so ohne =A0

Ja, aber das sollte doch mit 2 LAN-Modems an beiden Seiten kein allzu gro=DFes Problem darstellen. Der seriell2LAN-Konverter an G2 bekommt LAN- seitig eine andere IP-Adresse als "unser" Ger=E4t G1. Auf der anderen (PC-)Seite gibt es wieder ein LAN-Modem. An seinem Ethernet-Anschluss muss ich dann "nur" die TCP/IP-Pakete mit der IP-Adresse von G2 durch einen LAN2seriell-Konverter leiten. Am seriell-Ausgang von diesem ist nun P2 dran und merkt von der ganzen Aktion nichts. Die TCP/IP-Pakete mit der IP-Adresse von G1 schicke ich dann "direkt" an P1. Will sagen: Das Multiplexing/Demultiplexing findet auf TCP-/IP-Ebene statt, nicht auf serieller Ebene. Das ist doch das bessere Konzept als sich was serielles zusammenzuschustern.

...

Auf beiden Seiten LAN-Modems (s. o.)

=2E..

Ich darf WinXP voraussetzen.

Johannes

On 9 Jun., 06:40, Wolfgang Hauser wrote: =2E..

Ja, aber an der Infrastruktur kann ich leider nichts =E4ndern. Es gibt nur eine (gute alte) Telefonleitung. Ein Ziel wird nat=FCrlich auch sein, das ganze f=FCr ISDN, DSL, UMTS, GPRS,... anzubieten, es wird aber auf jeden Fall POT geben m=FCssen.

Gruss

Johannes

On 7 Jun., 12:14, Helmut Lammertz wrote: =2E..

Das kann ich mir vorstellen. Nein, ich will die Kopplung auf TCP/IP- Ebene machen, daf=FCr ist es vorgesehen. Serielle Kopplungen funktionieren selten oder nie, v.a. wenn es was selbstgebasteltes ist.

=DCbrigens: Das fertige Programm P2 kann sich zwar selbst einw=E4hlen, muss aber nicht. Es kann auch eine direkte serielle Verbindung geben. Und die soll der Serial2LAN-Konverter (m=FCssen wir den selbst "basteln"?) P2 vorgaukeln. Und das LAN-56kModem soll selber w=E4hlen.

Vielleicht weiss noch jemand ein oder zwei Adressen, wo ich mich diesbez=FCglich noch beraten kann.

Gruss

Johannes

Hallo allerseits,

vielen Dank f=FCr eure Antworten bis jetzt. Ich habe inzwischen die Erkenntnis gewonnen, dass ich doch serielle 56k-Modems nehmen muss.

56k-Modems mit LAN-Anschluss sind einfach zu exotisch. Devolo hat den Verkauf eingestellt, und bei 3COM/USRobotics schiebts bei Anfragen der eine auf den anderen, man will ja nicht beraten, "Kunde halts Maul und zahl was, aber lass uns in Ruhe, du hast eh keine Ahnung", ist wohl der Ton bei den Telecom-Unternehmen. Es war mir jedenfalls nicht m=F6glich, mich ohne Seriennummer von einem Ger=E4t, was ich noch nicht habe, durch die automatische Hotline-Vermittlung zu qu=E4len.

Aber zum Thema: Es muss also ein serielles Modem sein. Wenn ein externes serielles Modem von Windows oder einem Internet- Programm den Befehl bekommt, sich einzuw=E4hlen, wie l=E4uft das protokollm=E4=DFig ab? Da wird doch auch gewisserma=DFen TCP/IP so eingepackt, das es transparent =FCber die serielle Schnittstelle l=E4uft. Das Protokoll ist doch PPP oder SLIP. PPP ist doch "besser", aber auch komplexer. Was ich bei PPP nicht brauche, ist z.B., dass auch andere Protokolle dr=FCber unterst=FCtzt werden, ich brauche aber nur TCP/IP. Soll ich daher doch lieber SLIP nehmen? Aber das unterst=FCtzt im Gegensatz zu PPP keine Fehlererkennung. So, jetzt kommt noch das Modem hinzu. Es wird doch seriell =FCber AT- Befehle gesteuert, d.h. die ganze Einwahl usw. Oder ist das bei PPP dabei? Ich stelle mir das so vor: Wenn ich jetzt nur dieses eine schon bestehende Programm h=E4tte, das von Haus aus auf seriell zu Modem sendet/vom Modem empf=E4ngt, was w=FCrde ich dann im Hyperterminal sehen (nat=FCrlich wenn der Datenaustausch dadurch nicht gestoppt w=E4re)? Zuerst wohl ein paar AT-Befehle (als Characters) und dann wohl ein AT- Befehl, um die eigentlichen Daten zu senden. Dann m=FCsste doch auch folgendes m=F6glich sein: Unser Adapter hat 2Eing=E4nge, seriell und ethernet, und einen Ausgang zum Modem, seriell. Wenn er am seriellen Eingang AT-Befehle sieht, wei=DF er, dass das bestehende Programm, das Modem einw=E4hlen lassen will. Dann kommen die (noch nur seriellen) Daten. Die packt er in einen SLIP-Frames (?) mit fiktiver IP-Adresse. Die Daten am ethernet-Eingang packt er in SLIP-Frames mit einer anderen IP-Adresse. Am anderen Ende l=E4uft genau der umgekehrte Vorgang ab. Eigentlich m=FCsste es doch daf=FCr schon fertige Linux-Sourcen geben, kann mir da einer was empfehlen? Ich blicke noch nicht so recht durch mit den Protokollen. Sind diese AT-Befehle Bestandteil von SLIP/PPP? Das Problem der Linux-HowTOs ist nat=FCrlich auch, dass sie eher zum Konfigurieren sind, nicht so sehr zum Verst=E4ndnis, wenn man selber coden will. Also: F=FCr Hinweise bin ich dankbar.

Gruss

Johannes