Telexanschlusstyp kenntlich machen

Technischer Support bei Problemen mit i-Telex sowie dessen Komponenten.
Antworten

Topic author
Fernschreiber
Rank 3
Rank 3
Beiträge: 230
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Telexanschlusstyp kenntlich machen

#1

Beitrag: # 31495Beitrag Fernschreiber »

Hallo zusammen, speziell Entwickler

Im zuge der Entwicklung des neuen Rundsendedienstes ist ein Effekt aufgefallen, der die Welt nicht untergehen lässt, aber doch einer Diskussion bedarf wie ich meine. Mit Fred habe ich das schon mal am Rande besprochen. Ich denke aber das ist ein praktisches Beispiel um mal wieder etwas gemeinsam zu lösen. Dieser Effekt wird selten auftauchen, doch sollte man sich schon mal über prinzipielle Maßnahmen austauschen, die ja vielleicht auch anderweitig Verwendung finden können.
Auslöser ist indirekt eine historisch gewachsene Rufnummernliste, die mittlerweile kaum noch ein Rufnumernkonzept erkennen lässt, Die früher direkt erkennbaren Dienstegassen (erkennbar an bestimmten ersten Ziffern) sind nicht mehr vorhanden. Grund sind viele historische KG von Dienstemaschinen, die auf min. 5 Stellen erweitert wurden. So sind viele Nummern mit 1, 11 oder 7 bzw. 88 am Anfang vorhanden, die keine Dienste sind und von "normalen" Endstellen nicht zu unterscheiden sind. Das ist halt so und lässt sich nicht ändern, schliesslich soll jeder seine Wunschrufnummer bekommen.
Ein Problem stellt sich aber jetzt bei Rufnummernlisten für die neue Rundsendetechnik (11151/11152) dar. Diese baut die Verbindung zu den Zielen ja offline nach Auftragsaufgabe auf (analog zum letzten offiziellen Rundsendedienst). Wenn nun in der Rufnummerliste ein Tippfehler vorhanden ist, der zufällig anstelle des eigentlichen Ziels z.B. 885588 die 881188 beinhaltet (bei 11er und 7erNummern ähnlich) , kann es zu Verbindungen führen die letztlich zu nichts führen und zwei Dienste unnötig belasten. Die Rundsendedialer sind natürlich darauf vorbereitet das zu Beginn die unterschiedlichsten Möglichkeiten abgefangen werden, selbst wenn der KLKL-Dienst sein Menue versucht zu versenden, aber soweit muss es ja nicht kommen.
Eine Alternative wäre, nichts machen denn die beiden System werden sich baldmöglichst trennen und stört ja nicht. Der Auftraggeber bekommt sein Journal mit dem Fehler "sbb" oder "sbk" und bemerkt die falsche Rufnummer nicht mal.
Dieser Weg ist aber nicht meiner, da ich als gelernter Fernmelder eine optimiert geregelte Verfahrensweise bezüglich Verbindungen gewohnt bin.
Daher mein Vorschlag:

Um grundsätzlich Verbindungen zwischen Diensten (und nur darum geht es hier primär) zu verhindern (wer darin eine sinnvolle Anwendung sieht möge es an einem Beispiel erläutern), gibt es zwei existierende Möglichkeiten das zu verhindern ohne das die vorhandenen Stationen tangiert werden.
1) Verhinderung einer Verbindung schon im Vorfeld:
In dem Datensatz auf dem Tln-Server gibt es grundsätzlich drei Felder, die eine Identifizierung als Dienst ermöglichen:

40 byte name: The “long” identification of the peer (as shown in the subscriber list), coded in ASCII resp. ISO 8859-1.
oder
2 byte flags: Special “attributes” of the peer, encoded as a bit-masks in a 16 bit integer value:
Bit 0 (mask 0x01): always 0 (internally used to mark local entries which are not subject of “synchronisation” with the server)
Bit 1 (mask 0x02): always 0 (internally used to mark hidden (or “locked”) entries)
oder
1 byte type: connection type of the peer:
0: peer was deleted from the list
1: peer able to support the “texting baudot” protocol, accessible by a host name (known by public DNS servers)
2: peer able to support the “texting baudot” protocol, accessible by a given IP address (IPv4)
3: peer only supporting “ascii texting” (or a standard telnet client), accessible by a host name (known by public DNS servers)
4: peer only supporting “ascii texting” (or a standard telnet client), accessible by a given IP address (IPv4)
5: same as 2, but IP address may change frequently (“DynIP”-type)
6: not a real peer, but a regular email address.
Plan A:
In den 40 byte für den Namen könnte man ein eindeutiges Kürzel z.B "Service" o,ä, unterbringen. Kann man leicht als String checken.
Im Flag könnte ebenfalls etwas untergebracht werden, ist aber wahrscheinlich eher für den internen Gebrauch auf den Tln-Servern gedacht.
Im Byte für den Connection-Typ könnte man etwas unterbringen was kompatibel bleibt aber zusätzlich den Server kenntlich macht, der von den existierenden Clients ignoriert wird . Sollte das nicht möglich sein, bleibt nur die Identikikation nach Aufbau einer Verbindung.

Plan B
Nach dem Socket-Connect-Event wird zuerst das Versionspaket verschickt. Der Client muss darauf mit seinem antworten. Dieses darf bis zu 20Byte Nutzlast tragen, also Platz genug für eine "Kennung" ähnlich dem 40Byte Paket im Plan A. Sollte allerdings die in der Spec angedeutete Empfehlung, die Länge auf 6 zu begrenzen noch Gültigkeit haben, bliebe bei der derzeitigen Belegung nur ein "s" o.ä. übrig.

Wohlgemerkt, dieses betrifft nur Server untereinander und kann jederzeit schnell und "unbürokratisch" implementiert werden (Einfügen der Kennung und deren Auswertung). Da aber primär "normale" Client die Serverdienste nutzen "sollen", muß diese Lösung vollkompatibel zum bisherigen Geschehen sein. D.h. die i-telex Stationen oder "Fremdsysteme" müssen die Neuerungen ignorieren oder dürfen sie garnicht bemerken.

Ich hoffe diese Anregung führt zu interessanten Diskussionen, Fred stellt dabei natürlich eine zentrale Hauptfigur dar. Aber eine von allen (Entwicklern) getragene Lösung ist doch am Ende das Beste, auch für zukünftige und andere Diensteanbieter.

Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag (Insgesamt 2):
TheRaphISBRAND
Hauptnummer 25060
25061117 ufs lingen  T68d     Dw 890 
89899 schuett d        T1000   Dw 894  Hauptstelle
826433b vdm d         T100     Dw 891
841226 mizg d           Lo15     Dw 895
84635 norman d        T100     Dw 896
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Telexanschlusstyp kenntlich machen

#2

Beitrag: # 31500Beitrag FredSonnenrein »

Hallo zusammen, Hallo Willi,

Danke für den Beitrag, wo ich natürlich meinen Standpunkt darlege.

1. Der Bedarf nach dieser Information ist verstanden und wird auch von mir zur Lösungsfindung unterstützt.

2. Die Frage nach dem wie beginne ich mal mit den unrealistischen Möglichkeiten:

Plan B: Wäre machbar, die Grenze von 6 bezieht sich auf die Nutzdaten. Also ein Datenpaket mit den Nutzdaten Version 1, Kennung "serv" wäre sehr wohl möglich und kompatibel.

Plan A2: Zustzliches Bit in Flags: Das müsste wieder in alle Server aufgenommen werden und eine Gefahr zu Inkompatibilitäten besteht -> möchte ich nicht.

Plan A3: Zusätzliche Typ-Nummern für Server: Das lehne ich ab, da dann nicht nur die Server, sondern alle i-Telex Clients zu aktualisieren wären. (Denn andere Typen als 1 bis 6 werden von alten Versionen verworfen).

Plan A1: Kennung im Namen: DIes ist meine Vorzugslösung. Ich hatte ohnehin bereits vorgeschlagen, bestimmte "Merkmale" der Anschlüsse mit zu codieren. So hatte ich vorgeschlagen, dass am Ende des Namens (also der 40 Byte) Codebuchstaben stehen, die diese Merkmale kennzeichnen. Also NACH dem üblicherweise angegebenen Maschinentyp und zur Unterscheidung von diesem mit einem / eingeleitet.
Beispiel:
Fred, Braunschweig T68d /sz
/sz ist also die Kodierung der Merkmale.
Ich hatte folgende Ideen, welche Merkmale dargestellt werden könnten:

/z nur zeitweise erreichbar
/t Testanlage, Nachrichten werden nicht unbedingt gelesen
/s Streifenschreiber, für ASCII-Art nicht geeignet
/w Anschluss ist mit wechselnden Fernschreibern "verbunden" (Kennung passt also nicht unbedingt zur RUfnummer)
... und idee:
/a automatischer Teilnehmer (fände ich besser als "Server").

Wichtig: Das / kommt auch in Ortsbezeichnungen vor. Also nicht einfach nur nach / suchen, sondern nach dem letzten / und das ist auch nur dann ein "Merkmal-Kennzeichner", wenn keine Leerzeichen mehr folgen.

Eure Meinung bitte.

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag (Insgesamt 4):
FernschreiberTheRaphBjoernSISBRAND
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.

Topic author
Fernschreiber
Rank 3
Rank 3
Beiträge: 230
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Re: Telexanschlusstyp kenntlich machen

#3

Beitrag: # 31510Beitrag Fernschreiber »

Hallo zusammen, hallo Fred,
danke für deine Erläuterung und den Vorschlag. Diesen unterstütze ich auf jeden Fall, da er
a) keinerlei Updates auf bestehendem Equipment (ausser den Diensteservern die das unterstützen wollen) und
b) schon bei Abfrage der Nummer zwecks Auflösung nach iP/Domäne mitgeliefert wird. Eine Verbindung braucht erst garnicht aufgebaut werden und die Daten sind auf dem Tln-Server jederzeit sichtbar, können also auch bei der Auskunft mit eingebaut werden.
Bei der Abfrage der Daten im Baudot-Format kann man ja direkt auf die letzten zwei Zeichen im Paket triggern, da ist der "/" nur optisch interessant.
Wie das dann bei der ASCII-Abfrage geschieht, weiss ich nicht da ich die nicht nutze. Aber falls die 40Byte als String gesendet werden, sollte das auch gehen.
Wie Du schon schriebst, taucht der "/" in dem quasi Freitextfeld u.U. vorher auch auf. An diesem Punkt würde ich gerne den Umstand erwähnen, das in der Auskunft (118811) eine Suche nach Ort ziemlich schwierig ist, da es keinen eindeutigen Endpunkt gibt, der den Ort von den weiteren Daten trennt. Leerzeichen, ".","-" tauchen ebenfalls in Orten auf. Einzig alle "ausländischen" Einträge begrenzen den Ort mit einem "(", wo das Landeskürzel steht. Da ist selbst bei "Sean, St. Ippolyts (UK) FS200" eine eindeutige Ortssuche möglich.
Das ist bei "Isbrand, Bad Doberan Lo3000" kaum möglich. Ganz arg wird es dann bei "Historische Tel.-Zentrale Biesenthal", das strenggenommen ja nur aus dem Namen besteht obwohl der Ort drinsteht. Sehr verwundert war ich über die Einträge von den bei mir gehosteten Diensten, Dort steht im Namen am Ende eine Klammer, die aber nichts mit der Landesklammer zu tun hat. Z.B. "Flugwetter METAR de (Willi)". Dein Vorschlag würde dann wohl so aussehen wie bei "FabLab Dev, Wuerzburg /z", wo ich aber nicht wirklich weiss ob Wuerzburg als Stadt oder FS-Typ gilt.
Wenn dieses "Textfeld" schon zwecks Strukturierung am Ende angefasst wird, sollte dann nicht die gesamte Textformatierung vereinheitlicht werden? "Name , Ort Trennzeichen z.B. () und Rest bis /x" Dieses Feld hat ja bis jetzt nach meinem Wissen keinen technischen Bezug, eine grundsätzliche Strukturanpassung würde eigentlich nur meine Auskunft betreffen( bessere Suche) und evt. bei Detlef etwas. Mein Eintrag würde ich mir z.B. so wünschen: "Willi, Muenster () TXVst T100 /t " oder bei Diensten "Rundsenden de, Mstr () willi /a".
Wenn aber erstmal Daten drin sind (nach deinem Vorschlag) werden sich bestimmt Anwendungen dafür finden.
Das ist jetzt zugegeben ein Nebenschauplatz, aber wenn der Eintrag schon angepasst wird, kann man sich viel Arbeit sparen bevor später nochmal Hand angelegt werden muß.

Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag (Insgesamt 2):
TheRaphISBRAND
Hauptnummer 25060
25061117 ufs lingen  T68d     Dw 890 
89899 schuett d        T1000   Dw 894  Hauptstelle
826433b vdm d         T100     Dw 891
841226 mizg d           Lo15     Dw 895
84635 norman d        T100     Dw 896

TheRaph
Rank 2
Rank 2
Beiträge: 102
Registriert: Di 19. Mär 2019, 13:59
Wohnort: Elmshorn
Hauptanschluß: 666737 zms d

Re: Telexanschlusstyp kenntlich machen

#4

Beitrag: # 31511Beitrag TheRaph »

Hi. Bin zwar kein Entwickler, aber ich finde die Idee mit der Dienstekennung grundsätzlich gut.

Was meint ihr: Sollte es auch einen Buchstaben für das Ablehnen aller automatischer Dienste geben?
Und ggf. "o" für oeffentliche Einrichtung bzw. m für museum (öffentlich zugängliche, nicht private im Büro wie mein 5 Vitrinen)

Und auch die generelle Strukturierung von Namen finde ich gut. Dazu habe ich ein paar Ideen:

Ich würde Deutschland übrigens nicht als gesetzt ansehen, sondern das Länderkürzel verpflichtend machen. Dann wissen auch unsere nicht-Deutschländer-Kollegen wohin das Schreiben geht.

Wir hätten also folgendes:
Name (Realname, Nickname oder Dienste-Name) - pflichtfeld
Ort - optional
Länderkürzel - pflichtfeld
Maschine / Dienstbeschreibung - optional
Seriveflag

Als Trennung würde ich das Fragezeichen (?) oder plus (+) nehmen, das kommt weder in Namen noch in Orten noch sonst wo vor.

Name +Ort +Land +Maschine +dienst
Name? Ort +Land? Maschine? /dienst
Leerzeichen an den Trennern können nach optischen Gesichtspunkten (oder wegen Pkatz) gesetzt werden.
Nach dem split(string,"+") bei der Auswertung sollte man eh noch die Leerzeichen wegtrimmen.

Mir gefällt das "+" am besten:
Telekom FZZA +Elmshorn +D +HptSt +ws
Telekom FZZA +Elmshorn +D +T1000 +

Max +Schnefeld/Holst. +D +MyFS +tz
Hier mal Eure Beispiele
Fred +Braunschweig +D +T68d +sz
Sean +St. Ippolyts +UK +FS200 +
Isbrand +Bad Doberan +D +Lo3000 +

FabLab Dev +Wuerzburg +D ++z			<-- hier ist der optionale FS leer
FabLab Dev ++D +Wuerzburg +/z			<-- hier ist der optionale Ort leer falls Würzburg der FS währe

Histor. Tel.-Zentrale Biesenthal ++D++		<-- hier ist Ort, FS und Flag leer
Histor. Tel.-Zentrale +Biesenthal +D++		<-- oder nur FS und Flag leer

Flugwetter METAR de (Willi) ++D++a		<-- definitiv ein Auto-dienst - sonst alles optionale leer

Willi +Muenster +D +TXVst T100 +t
Rundsenden de +Muenster +D +willi +a
Gruß Raph
Folgende Benutzer bedankten sich beim Autor TheRaph für den Beitrag:
ISBRAND
Aktuelle FS am Arbeitsplatz:
666737 zms d - T1000 - Erreichbar 24/7
181270 sopex d - T100 - Erreichbar 24/7
218379 - Lo T36 - Kein KG - Streifenschreiber (offline)

In Arbeit:
49515 vogt d - T37g - Bei bedarf
493289 webro d - Lo15
218318 fza d - T68d

Topic author
Fernschreiber
Rank 3
Rank 3
Beiträge: 230
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Re: Telexanschlusstyp kenntlich machen

#5

Beitrag: # 31513Beitrag Fernschreiber »

Hallo Raph,

danke für deine Beispiele, wäre eine praktikable Möglichkeit, aber mal schauen was da noch kommt, ich bin da offen für Ideen, Umsetzen muß es auf den Servern ja Fred, ist ja nur Texting, aber muß gemacht werden.
Deinem Punkt einen Kenner zum Ablehnen von automatischen Diensten einzusetzen kann ich allerdings in diesem Hobbynetzwerk rein garnichts abgewinnen. In öffentlichen Netzen ist das natürlich durchaus sinnvoll, einige Telefonrouter lassen das ja zu. Gegen Anrufe kann man sich grundsätzlich nicht stemmen, ist auch nicht Sinn dieser Gemeinde. Im Gegenteil, es wird oft moniert das zu wenig Verkehr entsteht und die FS nicht rattern. Die automatischen Anrufe von Diensten sind sehr überschaubar. Mir fällt gerade nur der Abodienst ein, den man aktiv abonieren muß, die alte und neue Rundschreibeeinrichtung und Detlefs gelegentlicher KG-Test. Letzterer dient der Aktualisierung der KLKL-Liste und hilft Finn beim erstellen der Telexbücher. Wer sich dem entziehen möchte kann Detlef eine Nachricht schicken. Es gibt auch das Rundschreibefeature in einigen modernen FS bzw. softwarebasierten Versionen, die werden sich wohl kaum an den Blocker halten.
Die Rundsendeeintichtungen werden üblicherweise von festen Gruppen benutzt, die diese Möglichkeit schätzen. Wer da nicht mitmacht wird wohl kaum belästigt. Andererseits ist diese Möglichkeit die zeitsparendste, um z.B. wichtige Infos an Teilnehmer zu schicken die hier im Forum nicht (so) aktiv sind.
Es ist ja kein Newsletter der pausenlos anruft und Papier volldruckt. Wenn man mit solchen Ideen anfängt, endet das womöglich mit der Forderung nach Blacklists in der Ethernetkarte. Zudem müssen die Dienste das ja unterstützen, mein RS-Dienst soll nur auf andere Dienste reagieren, denn das ist Unsinn und sollte nicht stattfinden, daher dieser Thread. Wenn sich jemand durch Rundsendungen belästigt fühlt, kann die Person das mit dem Absender ausmachen. Sollten die Admins des Tln-Servers einen solchen Blocker eintragen, müsste die Berücksichtigung dessen ja als "mandatory" eingestuft werden, bei einem Open-Source-Projekt sehr fraglich. Mehr gibt es dazu von meiner Seite nicht zu schreiben.
Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag (Insgesamt 2):
FredSonnenreinISBRAND
Hauptnummer 25060
25061117 ufs lingen  T68d     Dw 890 
89899 schuett d        T1000   Dw 894  Hauptstelle
826433b vdm d         T100     Dw 891
841226 mizg d           Lo15     Dw 895
84635 norman d        T100     Dw 896
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Telexanschlusstyp kenntlich machen

#6

Beitrag: # 31516Beitrag FredSonnenrein »

Hallo zusammen,

grundsätzlich habe ich folgende Struktur versucht einzuhalten:

<Vorname>, <Ort> [(<Land>)] [<Maschinentyp>] [/<Merkmale>]

Notation ist denke ich klar, <xxx> = Feld, [xxx] = optionaler Teil, alle andere Satzzeichen sind bindend.
In den Feldern Land, Maschinentyp und Merkmale dürfen keine Leerzeichen sein, somit wäre ein intelligenter Parser in der Lage, alles korrekt zu zerlegen.
Auch bei dem Beispiel "Isbrand, Bad Doberan Lo3000" ist die Grenze zwischen Ort und Maschinentyp klar, da der Maschinentyp nur ein Wort sein darf. Allerdings müsste dann eigentlich der Maschinentyp bindend sein.

Für "nicht personenbezogene" Einträge ist aber tatsächlich Wildwuchs eingetreten.

Generell frage ich mich, warum eine "harte" Strukturierung "gebraucht" wird. Wer würde diese nutzen wollen?
Denn bei jeder Regel findet sich immer ein Fall, der nicht "schön" in die Regel passt.

Über neue Regeln wie "auch (DE) ist als Länderkürzel zu verwenden" lasse ich gerne mit mir reden.

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
ISBRAND
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Benutzeravatar

DF3OE
Founder
Founder
Beiträge: 3066
Registriert: Di 7. Jun 2016, 09:45
Wohnort: Edemissen - Blumenhagen
Hauptanschluß: 925302 treu d
Kontaktdaten:

Re: Telexanschlusstyp kenntlich machen

#7

Beitrag: # 31518Beitrag DF3OE »

in ja absoluter Laie aufebiet, aber bitte übertreibt es nicht. Wenn eine Maschine nicht von AUßen erreicht werden soll, dann steht sie einfach nicht mit Nummer im Teilnehmerserver. Rauswählen kann man ja trotzdem.
Und "echte" Landesvorwahlen (nicht technisch) brauchen wir auch nicht, da das gesamte Netz ja international ein einziges ist und viele
auch Maschinen mit Kennungsgebern aus anderen Ländern benutzen. Es ist ein Sammlernetz und kein Ersatz für das originale Telex. ;)

Ansonsten würde ich in der Teilnehmerliste gegen den "WIldwuchs" eher Aufräumen vorschlagen....

Obige Äußerungen beziehen sich nicht auf das technische Protokoll.
Folgende Benutzer bedankten sich beim Autor DF3OE für den Beitrag (Insgesamt 3):
duddsigWolfgangHISBRAND
mfg
henning +++

925302 treu d - T1000Z (Hauptanschluss)
55571 fvler a - T100S
210911za hmb d - T150 (Werkstatt)
218308 test d - T1000S/LS (Werkstatt)
925333 =treu d (Minitelex Sanyo SF100) defekt
Fax G2/G3: 05176-9754481 (Sanyo SF100 Thermofax) defekt
Benutzeravatar

duddsig
Rank 11
Rank 11
Beiträge: 1114
Registriert: Sa 18. Feb 2017, 20:47
Wohnort: Großpösna bei Leipzig
Hauptanschluß: 7977457 knawu d

Re: Telexanschlusstyp kenntlich machen

#8

Beitrag: # 31519Beitrag duddsig »

Ich bin auch Laie, aber ich sehe das auch so wie Henning. Ich habe auch einen Kennungsgeber mit nur Bustaben in meinem T100, weil ich den auf Grund seiner Geschichte so behalten möchte, benutze aber die ehemalige originale Nummer der Maschine. Außerdem ist es auch ein Bastelnetz, wo immer mal wieder was anderes dran hängt. Und eine Amateufunkkennung habe ich in meinem T34f.

Allerdings würde ich mir nun wierder eine Möglichkeit zum Sperren für ALLE automatischen Dienste wünschen. Denn mein Streifenschreiber T36Lo kann nach einer Vegrießgnattelung durch den Streifen nicht mehr umschalten nach ZI. Es war nur der Scanner von Detlef, der dann versucht hat immer wieder eine Kennung zu bekommen, das aber nicht mehr ging. Den würde ich für sowas z.B. sperren wollen, für bewußt gewollte Verbindungen jedoch nicht. Das möchten bestimmt viele für Streifenschreiber, denn wer möchte ein ellenlanges Rundschreiben vom Streifen lesen....

Die Maschinen in meinem "Wählersaal" werden auch nicht immer kontrolliert.
Folgende Benutzer bedankten sich beim Autor duddsig für den Beitrag:
ISBRAND
1=T51✦7977457 knawu d
2=T100 ✧7262124 keba d , ✧de afbirq nj
3=T63 ✦48936 t63 pl, ✦87724 ksbo dd
4=AB ✦512283 rfta dd
5=T36Lo ✦15199 tentstoer
6=Lo15 ✦711 pruef att DuWa=711711
7=T51 ✦34131bf dr z.Z. offline
8=T63 ✦512283 rfta dd
Benutzeravatar

FredSonnenrein
Founder
Founder
Beiträge: 2317
Registriert: Fr 3. Jun 2016, 13:49
Wohnort: Braunschweig
Hauptanschluß: 8579924 hawe d

Re: Telexanschlusstyp kenntlich machen

#9

Beitrag: # 31520Beitrag FredSonnenrein »

Hallo zusammen
duddsig hat geschrieben: Do 2. Jun 2022, 10:38 Ich bin auch Laie, aber ich sehe das auch so wie Henning. Ich habe auch einen Kennungsgeber mit nur Bustaben in meinem T100, weil ich den auf Grund seiner Geschichte so behalten möchte, benutze aber die ehemalige originale Nummer der Maschine. Außerdem ist es auch ein Bastelnetz, wo immer mal wieder was anderes dran hängt. Und eine Amateufunkkennung habe ich in meinem T34f.
Dass mal der Kennungsgeber von der Rufnummer abweichend ist, ist halt so. Damit muss ein jeder klarkommen.
duddsig hat geschrieben: Do 2. Jun 2022, 10:38 Allerdings würde ich mir nun wierder eine Möglichkeit zum Sperren für ALLE automatischen Dienste wünschen. Denn mein Streifenschreiber T36Lo kann nach einer Vegrießgnattelung durch den Streifen nicht mehr umschalten nach ZI. Es war nur der Scanner von Detlef, der dann versucht hat immer wieder eine Kennung zu bekommen, das aber nicht mehr ging. Den würde ich für sowas z.B. sperren wollen, für bewußt gewollte Verbindungen jedoch nicht. Das möchten bestimmt viele für Streifenschreiber, denn wer möchte ein ellenlanges Rundschreiben vom Streifen lesen....
Na ja, wenn ein Fernschreiber gar nicht mehr richtig geht, dann sollte dieser ganz ausgeschaltet sein.
Automatische Dienste, die "irgendwo" anrufen, gibt es m.E. nur in Form des Scanners von Detlef.
Und dies zu unterdrücken, ist technisch nicht möglich bzw. nur im Server-Dienst implementierbar.

Ich habe meinen Streifenschreiber
1. nur tagsüber freigeschaltet.
2. generell gegen Umleitungen von besetzten oder gestörten Anschlüssen gesperrt.

Und das Merkmal "/s" war ohnehin auf der Ideenliste zu den "Merkmals-Angaben", dies könnte also ausgewertet werden.

Viele Grüße,

Fred
Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
ISBRAND
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.

Topic author
Fernschreiber
Rank 3
Rank 3
Beiträge: 230
Registriert: Sa 17. Dez 2016, 15:28
Wohnort: Münster
Hauptanschluß: 25060 schuett d
Kontaktdaten:

Re: Telexanschlusstyp kenntlich machen

#10

Beitrag: # 31523Beitrag Fernschreiber »

Hallo zusammen,
@ Henning:
2er Satz: es ging Raph nicht um die generelle Erreichbarkeit, sondern die von Automaten. Kann man Ansatzweise durchaus verstehen, siehe Marco der von Detlef's Scanner nicht behelligt werden möchte. Und wie ich gerade lese hat Jens auch ein Problem damit. Also Info an Detlef. Aber so eine anfällige Maschine würde ich grundsätzlich von aussen sperren.
3er Satz: es geht nicht um "echte" Landesvorwahlen, wo ist das denn lesbar? Es geht nur um den Trenner (xx) zwischen Ort und dem Rest des Textes. Warum wird der nur bei "ausländischen" Einträgen verwendet wenn es doch ein großes einziges weltweites Netz(durchaus imposant) ist, ist problemloser nutzbar zur Separierung des Ortes als wie nach "spaces" und "nicht spaces" zu suchen ;vereinheitlicht die Datensätze und ist primär (Stand heute) für die Suche in der Auskunft 118811 hilfreich.
4er Satz: es ist schon etwas mehr als ein Sammlernetz, das sehe ich bei meiner individuellen Kommunikation und speziell bei den Rundsendungen.
Ein Ersatz des Originals kann und wird es niemals sein.
5er Satz: nur zu

@ Fred
Deine Notation ist OK, aber die Klammen würde ich aus Gründen der Vereinheitlichung nicht als Option sehen. Es ist ein Ankerpunkt im String für jeden Parser und auch optisch, selbst wenn sich dann doch mal ein illegales Leerzeuichen einschleicht. Ich habe in der Auskunft notgedrungen zwei Auswerte-Strategien integriert, wobei die auf Klammern basierende wesentlich einfacher und exakt arbeitet, die andere mehr als "String in String Suche" läuft, das würde ich gerne abstellen.
Zur Zerlegung von Strings in Python3 (wird anderswo genauso sein): Die Funktion .split("x") teilt einen String an allen Stellen wo ein "x" steht und bildet ein Array/Liste. Dadurch ist in einem Schritt eine eindeutige Zerlegung in Teilstrings möglich. Leider geht das im jetzigen Format nicht. Der einzige verlässliche Trenner ist das "," nach dem Namen. Eine weitere Zerlegung nach "space" macht wenig Sinn, die kommen ja im Ort schon vor. Die saubere Lösung wäre das "," generell als einzigen Trenner zu benutzen, dann wären die Klammer und alle anderen Einträge tatsächlich optional nutzbar. Wenn dann die Reihenfolge Name, Ort,Land eigehalten wird und die Merkmale grundsätzlich am Ende stehen (sind durch "/ "identifizierbar) wäre sogar der jetzige Maschinentyp notfalls nochmal teilbar bzw. " " in den einzelnen Optionen sind denkbat. Wer weiß ob diese Eintäge mal zu irgendwas genutzt werden, dann sollten sie strukturiert vorliegen. Bei Einträgen wie bei Museen, die nichtmal einen Trenner "," haben, gilt dann eben die Reihenfolge : ist nur der Name.
Noch ein gerade aufgefallener Eintrag: "Andreas, Neundorf b. Bad Lobenstein" oder neu :"Andreas, Neundorf b. Bad Lobenstein /z"
Wie zum Teufel soll ein Parser hier den Ort vernünftig rausarbeiten. Die Vorgabe ist:<Vorname>, <Ort> [(<Land>)] [<Maschinentyp>] [/<Merkmale>]
alt: Der Name ist klar, der erste Ortsname auch. Das b wird dann als Land erkannt und verworfen und Bad Lobenstein als ungültiger Maschinentyp einsortiert.
neu: Der Name ist klar, der erste Ortsname auch. Das b wird dann als Land erkannt und verworfen, Bad wird zum Maschinentyp und Lobenstein zum Merkmal. das eigentliche Merkmal fällt formlich hinten raus, es sei man checkt erstmal ob das Merkmal enthalten ist. Wird aber nich besser, nur anders.
Anderer Ansatz:
neu:Der Name ist klar, der erste Ortsname auch. Dann checken ob Klammern da sind und wieviele Spaces noch kommen. in diesem Fall 4. Das sind zuviel, also gehört das b noch zum Ort, bleiben 3 Space. das ist immer noch zu viel, also Bad zum Ort. Bleiben 2 Space. das passt zur Vorgabe, also wird Lobenstein zum Maschinentyp und "/z" zum Merkmal. alles passt, stimmt aber nicht. Auch wenn man von hinten zählen würde, es kommt das gleiche raus.
Eintrag mit "," getrennt = "Andreas, Neundorf b. Bad Lobenstein, /z"
Der Name ist klar, der Ortsname auch da er bis zum nächsten "," geht, danach gibt es nur noch einen Eintrag der eindeutig als Merkmal identifizierbar ist.
Ähnlich wäre es mit Landesklammern: "Andreas, Neundorf b. Bad Lobenstein (de) /z"
Der Name ist klar, der Ortsname auch da er bis zum nächsten "(" geht, danach gibt es noch den Eintrag Land und einen,der eindeutig als Merkmal identifizierbar ist. sollte zwischen ")" und "/" noch etwas stehen, kann es nur der Maschinentyp sein, sogar als "Lo 15b".
Übrigen ist ja der gesamte Datensatz struktruriert mit "," getrennt und in der Zahl festgelegt. Ist keine IP vorhanden, ist das Feld Domäne benutzt oder umgekehrt. Auch die Durchwahl am Ende ist immer ein Feld, auch wenn es leer ist "". Ist mit einem Schritt gesplittet und analysiert.
Viel Spaß beim lesen und/oder nachdenken über alternative Wege.

Noch einen schönen Tag
Gruß
Willi
Folgende Benutzer bedankten sich beim Autor Fernschreiber für den Beitrag:
ISBRAND
Hauptnummer 25060
25061117 ufs lingen  T68d     Dw 890 
89899 schuett d        T1000   Dw 894  Hauptstelle
826433b vdm d         T100     Dw 891
841226 mizg d           Lo15     Dw 895
84635 norman d        T100     Dw 896
Antworten

Zurück zu „Technischer Support (i-Telex)“