Probleme mit dem internationalen sowie dem mobilen Arbeiten mit David

Zitat von twmemphis

In unserem Büro München haben wir DSL mit irgendwas um 50MBit, hier am Server in Oberursel eine synchrone 30Mbit Leitung (ab Juni 600Mbit). Auch die Kollegin in Rostock hat eine 100Mbit DSL Leitung.

Beide, die Münchener als auch die Rostocker, haben sporadisches Einfrieren des Clients für ca 30 Sekunden.

Da es sich um Internet-Kabelverbindungen handelt ist es eher unwahrscheinlich, dass so lange Internet-Unterbrechungen vorliegen.

Die von Dir für die deutschen Standorte geschilderten Probleme klingen nach DSL Routern mit Problemen bei der gleichmäßigen Aufteilung von Datenströmen.

Kann es sein das da über die gleichen Leitungen auch noch ganz gern nebenher der ein oder andere Chromium basierte Webbrowser aktiv ist? Vielleicht auch noch mit dem einen oder anderen (mehrere Nutzer an einem Standort) Web Radio Stream? Chromium hat da so ein par unschöne Eigenschaften was sein Verhalten angeht sich zeitweilig bis zu 100% der Bandbreite einer Netzwerkverbindung zu krallen, das ist ganz nett wenn man gerade einen chromium basierten Browser für einen Download oder einen Stream nutzt, aber so gar nicht angenehm wenn man "nebenbei" was anderes tun will das auch nur im Ansatz interaktiv ist.

Zitat von twmemphis

Warum friert die App ein, wenn die Verbindung mal schwergängig ist? Dann könnte man doch dem Benutzer wenigstens erlauben im Editor weiter zu tippen und muss nicht gleich alles zum Einfrieren bringen, denn es ist ja gerade nichts super-eiliges an Daten zu übertragen.

An der Stelle hast Du natürlich völlig recht, wenn Tobit den David Client sauberer programmiert hätte müsste der Editor im Vordergrund gar nichts davon mitbekommen wenn es im Hintergrund gerade irgendwo klemmt.

Zitat von twmemphis

in einer Kommunikation mit Tobit via Intercom von 2017 wurde mal empfohlen einen Loopback Adapter einzurichten. Kennt das jemand? Das simuliert wohl eine beständige Verbindung. Vielleicht erledigt sich damit ja das "einfrieren" ?

"Loopback" macht jetzt für mich irgendwie grad keinen Sinn.

Sinn machen würde hingegen ein VPN Client der ein niedriges Keepalive Intervall hat um die Verbindung aktiv und damit mehr responsive zu halten und noch dazu udp statt oder zusätzlich zu tcp zur Übertragung nutzt.

Generell würde ich mir Eure Router und was die sonst so zu tun haben näher anschauen.

30 Sekunden einfrieren ist nämlich schon ziemlich extrem, das kenne ich nicht mal wenn ich im Homeoffice neben einem Chrome welcher einige hundert Tabs in einem dutzend Fenstern offen und aktuell hält remote arbeite, da sind es allenfalls mal einstellige Sekunden und das auch nur wenn mein dortiger Router grad richtig am ackern ist.

twmemphis und nur mal so zur Einschätzung, die 30 MBit Synchron, wie sind die realisiert? SDSL? Und wie viele Leute arbeiten an dem Standort? Wie viele greifen remote auf Dienste dort zu? Und was steht da für ein Router/Firewall?

O.K. ich hätte schreiben sollen:

"Generell würde ich mir an Eurerer Stelle Eure Router und was die sonst so zu tun haben näher anschauen."

Sorry, ich hab nen Vollzeit Job und bin bereits jetzt durch die gesetzlichen Arbeitszeitbeschränkungen daran gehindert noch mehr zu arbeiten.

In meinem Status ist Freizeit unbezahlbar.

Dennoch beteilige ich mich gern an Foren und Austausch zum Thema Problemlösungen, denn davon habe auch ich etwas

Ich kann aber allenfalls die Richtung weisen, nicht Probleme bis zum Ende lösen, das übersteigt meine freien Ressourcen...

Zitat von riawie

Das was Du da beschreibst lässt auf ein Problem des Routers bei Euch lokal schließen.

Wir hatten exakt das gleiche Problem auch schon bei einigen Kunden im LAN, da kann ich Probleme mit Routing, Firewall, DNS usw. definitiv ausschließen. Alle anderen Applikationen incl. Zugriff auf Terminal Server, Warenwirtschaft, SQL-Verbindungen usw. liefen störungsfrei, nur der David-Client hing nach einer Arbeitspause reprodzuierbar.

Ist natürlich gut möglich, dass das letztlich an einem speziellen NIC-Treiber lag oder so (im LAN waren nur wenige PCs betroffen, und die meisten Kunden haben derartige Probleme nicht). Dennoch drängt sich der Eindruck auf, dass Tobit an der Stelle mal wieder sehr wenig fehlertolerant denkt. Andere Applikationen mit Client-Server-Architektur bekommen das deutlich besser hin.

Edit: jetzt war ich mit den Urhebern der verschiedenen Aussagen durcheinander gekommen, also mal sortieren ...

nordtech das Problem auf was ich mich bezog, hatte in der Tat nicht twmemphis oben beschrieben, sondern Du selbst... , also ein Client der obwohl er im LAN sitzt nicht auf die Interne Adresse des David Servers zugreift sondern auf dessen externe Adresse, welche eigentlich nur genutzt werden soll wenn der Client sich außerhalb des Netzes befindet und dann nach längerer Nichtnutzung einfriert sobald man ins Fenster klickt und dann erst nach einer geduldigen Pause wieder reagiert sollte auf keinen Fall auftreten wenn der Client auf die LAN Adresse des Servers zugreift.

Passiert Dir das auch ohne das der Client über die WAN Adresse des Routers und Portforwarding auf den David Server im LAN zugreifen muss hast Du definitiv ein Problem im LAN.

Wenn es allerdings so wie auf der vorigen Seite von Dir beschrieben passiert hat das seine Gründe in der Art wie die meisten Router derartigen maskerading Nat Traffic zur eigenen externen IP Adresse und anschließendem DNat Portforwarding nach drinnen innerhalb ihres Kernels abwickeln.
Die Gründe dafür was da intern passiert zu erläutern sprengt hier leider meinen zeitlichen Rahmen den ich bereit bin darauf zu verwenden.
Entscheidend ist das man es aus dem Weg räumen kann und das man dazu die Anwender nicht zwingen muss immer an das umstellen des Server(namen)s zu denken wenn sie von draußen ins Office kommen

Der geschickteste Fall sowas zu lösen ist der das man für den David Server einen eigenen öffentlich auflösbaren Hostnamen vorsieht, der aus dem Internet aufgelöst immer zur öffentlichen IP-Adresse des Routers mit dem Portforwarding auf den David Server führt.
Zusätzlich konfiguriert man den DNS Server im Netz wo der David Server steht so, das er auch diesen öffentlichen fqdn Hostnamen auflöst, allerdings nicht mit der öffentlichen IP-Adresse des Routers, sondern mit der internen IP Adresse des DAVID Servers im LAN.

Damit entfällt im LAN das Thema Maskerading Nat nach Portforwarding über die öffentliche IP Adresse des Routers und damit entfallen auch die dadurch entstehenden Probleme wenn der David Client eine Zeit lang nicht genutzt wurde.

Diese Lösung funktioniert immer.

Es gibt noch andere Lösungsansätze dafür, allerdings ist es da von der genauen Konstellation der vorgefundenen Umstände abhängig ob sich ein Erfolg einstellt und wie man genau dahin kommt, daher verzichte ich hier auf weitere Erklärungen dazu.

---------------
Sorry für das vermischen der unterschiedlichen Problembeschreibungen...
Ich hoffe ich habs nun wieder sinnherstellend aufgeräumt.

Die Probleme von twmemphis sind ja doch etwas anders gelegen und eigentlich hatte ich versucht mich auch rein darauf zu beschränken...

Moin,

Outlook und Tobit Active Sync geht ja nicht, weil das Ziel: Word, Pdf aus dem TAS ggf. aufrufbar haben nicht ginge.

Outlook kann das nicht.

Outlook + Tobit Active Sync würde aber dein Ziel "User können die Mails auch im Flieger offline bearbeiten" lösen.

Kennst du ja bestimmt.

Zitat von twmemphis

Nein, die Clients sitzen in Rostock oder München an einem Laptop mit DSL Anbindung und connected mit ihrem Online Client zum Server in Oberursel.

Die Rechner in Oberursel mit LAN Direktverbindung zum Server haben kein Problem, hier ist alles flott.

Oder hast Du es anders verstanden bzw gemeint

*argh* *narf* der Thread wird langsam unübersichtlich und ich hab Nordtechs Bericht mit Deinem in einen Topf geworfen

Ich werde den Kommentar mal bearbeiten, so das es wieder Sinn ergibt...

Sorry für die Verwirrung...

Eigentlich soll es ja nur um Deine Problemstellung gehen.

In Deinem Fall würde ich da wohl ein VPN einziehen mit angepassten Keepalives um das Thema NAT auszuschalten.

Wie gesagt, wir haben die Probleme nicht, unser David Server hat aber auch eine dedizierte eigene öffentliche IP und hängt an einem Anschluss der ihm ausreichende Bandbreite garantiert.

twmemphis

Sorry, der Absatz:

"Der geschickteste Fall sowas zu lösen ist der das man für den David Server einen eigenen öffentlich auflösbaren Hostnamen vorsieht, der aus dem Internet aufgelöst immer zur öffentlichen IP-Adresse des Routers mit dem Portforwarding auf den David Server führt.

Bezog sich rein auf das von nordtech geschilderte Problem das er ab und an mit einem Client der denkt er würde noch remote auf den David Server zugreifen müssen lokal im LAN neben dem David Server sitzt.
Das trifft auf Deine Konstellation aber ja gar nicht zu, also kannst Du den Absatz wieder vergessen.

entsprechend ist Deine Überlegung hier:

Zitat von twmemphis

Wir haben bereits einen öffentliche Hostnamen (mail.xxxx.de), welche nicht zum Router, sondern direkt zur IP Adresse des David Servers führt. Evtl geht es auch erst durch den MailMarshal, aber das kläre ich gerade.

Aber jedenfalls zeigt der Hostname aufgelöst nicht auf die IP des Routers. Sollte es besser zum Router zeigen?

leider durch meine Konfusion von oben grad fehlgeleitet und hilft Dir nicht weiter...

Um Dein Problem weiter einzukreisen müsste man natürlich wissen wie die genaue Aufstellung der Infrastruktur beim entsprechenden Server wirklich ausschaut.

Wenn man das nicht im Deatil anschaut wird das leider ein wenig Kaffeesatzleserei bleiben.

Ich kann aktuell halt nur eines mit Verbindlichkeit sagen und das ist:

Wenn der David Server performant ans Internet angebunden ist und ihm weder jemand der die gleiche Leitung nutzt die Bandbreite raubt, noch irgendwer an seinem Anschluss die eingehenden Verbindungen der Clients kaputtfiltert.

Dann können Clients welche selbst ebenfalls Internetzugänge haben bei denen sie nicht gegen andere Bandbreitenterroristen - wie z.B. gerade einem breitbandigem Stream lauschende Chromium Browser oder ähnlich kannibalisierende datenhungrige Anwendungen - selbst dann ordentlich remote mit einem David Server arbeiten wenn es gelegentlich zu Lags kommt.

30 Sekunden oder längeres einfrieren kommt dann nicht vor.

Viele Probleme die es aufgrund von Einschränkungen der Internetzugangsqualität auf einer von beiden Seiten gibt lassen sich mit einem fein getunten VPN deutlich abmildern.
Aber es muss einem klar sein das man dann daran arbeitet Probleme zu umschiffen die man besser abstellen sollte.
Leider kann man sie nicht immer alle abstellen, also muss man manchmal doch umschiffen.

Würde man beide Seiten per IPv6 anbinden und beim mobilen Nutzer alle nativen Möglichkeiten für nomadische IPv6 Nutzung voll ausschöpfen würde das übrigens den Idealzustand darstellen.

Allerdings hab ich das selbst hier - außer in einem Testszenario - noch nicht umsetzen können weil nicht überall natives IPv6 verfügbar ist.
Meine Aussagen das sich flüssig remote mit einem mobilen David Client auf einem David Server arbeiten lässt als säße man im Büro (das halt nur ein schmalbandiges LAN hat) beziehen sich also rein auf IPv4 Umgebungen und machen kein IPv6 zur Bedingung.

Das Problem was bleibt ist das sich jemand Eure Anbindung genau ansehen und optimieren sollte.
Das ist normaler Weise eine einmalige Investition die sich aber lohnt.

Natürlich kann man das alles auch durch ein anderes System ablösen welches von vornherein auf stark nomadische Nutzung konzipiert wurde, das hat dann halt seine eigenen Constraints.

Aber zu sagen das ginge mit einem David nicht tut dem David halt schlicht unrecht.
Vielfach sind es schlicht behindernde IDS Systeme und nicht gut abgestimmte Firewalls welche den David beim Einsatz außerhalb des LANS kastrieren.

Das Problem dabei ist das die wenigsten Dienstleister für David das Mandat und oft auch nicht die Expertiese haben sich auch um die korrekte Außenanbindung des Servers und der nomadischen Clients zu kümmern. Schuld ist dann aber natürlich der David...

Hallo riawie,

deine Aussagen zum remote Arbeiten mit dem David Client interessieren mich sehr. Denn auch ich habe mindestens einen grösseren Kunden der damit massive Probleme hat.

Die Struktur ist dort so:

Haupstandort SDSL 50MBits, dort steht auch der Server (wird wohl auf 100/100MBit aufgerüstet)

Drei weitere Standorte mit VDSL zwischen 25MBit - 100MBit

Alle Standorte sind untereinander "site2site" über LANCOM Router vernetzt.

An den Aussenstandorten arbeiten die Mitarbeiter mit dem nativen David Client ,

als David Server ist direkt die IP des "Servers" eingetragen, dort wird ja hingeroutet...

An diesen Standorten kommt es insbesondere beim Versenden grösserer Mail zu

extremen Wartezeiten (bis über eine Minute!) bis der Client wieder reagiert.

Hier ist es so, erst wenn der Anhang am Server angekommen ist (PDFs mit tlws. 5-10MB)

reagiert der Client wieder! Auch das wechseln von Ordner mit sehr vielen Mails im root-Verzeichnis

dauert oft lange, der Wartekreisel ist üblich ...

Wäre da tatsächlich die Portweiterleitung die bessere (schnellere) Lösung?

Anfangs war es bei deutlich geringeren Bandbreiten (am Hauptstandort nur 2.5MBit

CompanyConnect) noch viel schlimmer, zufriedenstellen ist die Situation aber auch jetzt

noch nicht.

Deswegen ist es geplant , das die Mitarbeiter der Ausstenstellen zukünfigt alle auf einem

Terminalserver arbeiten, denn auch der Zugriff auf weitere Daten und Dokumente soll

beschleunigt werden...

Hallo,

mich würde mal interessieren was wäre wenn Tobit Client auf einem Server mit NVME SSD + 500mbit Internet-Anbindung laufen würde, ob es über Port 267/268 dann zu keinen "LAGs" mehr kommt

Das in dem Archive dann weniger als 5000 Items sein sollten ist klar

burkhard komplexe Situation, je nach dem was da sonst noch alles zugegriffen werden soll und wie viele Mitarbeiter an den Außenstandorten arbeiten ist ein Terminalserver Ansatz in solch einer statischen Konstellation durchaus der richtige Ansatz.

Dabei muss dann allerdings dar Internetzugang am Hauptstandort auch berücksichtigen das die nun virtuell dort hinzukommenden Mitarbeiter unter Umständen ebenfalls noch zusätzlichen Internettraffic generieren.

Ich würde bei so einem Ansatz dazu tendieren den gesamten VPN Traffic per QoS zu priorisieren.

Wenn an den Standorten auch noch Telefonie über VoIP genutzt wird würde ich dafür eigene Leitungen schalten oder wenn das nicht möglich ist dem VoIP Traffic eine höhere QoS Priorisierung angedeihen lassen.

Wichtig ist das aller normaler Internet Traffic an allen beteiligten Standorten die niedrigste Priorität bekommt.

Es kann dennoch sein das normaler Surftraffic (Webbrowser) dann am Hauptstandort Probleme bereitet, in dem Fall sollte man die Bandbreite des Hauptanschlusses für Surftraffic so lange begrenzen bis das arbeiten flüssig wird, oder alternativ für Surftraffic und VPN getrennte Internetanschlüsse nutzen.

In einem Alternativszenario ohne Terminalserver müsste man erst mal ebenfalls eine Trafficpriorisierung einrichten. Dann könnte man mal versuchsweise den David Server für die Außenstellen Firewallen, also dafür sorgen das er für die Außenstellen nur noch auf den Ports 443 und 267 erreichbar ist (damit ist aber kein Portforwarding gemeint, sondern schlicht ein Satz Firewallregeln im VPN) . Das zwingt die David Clients den David Server wie einen remote Server anzusprechen statt wie einen Server im lokalen Netz und ihren Bandbreitenhunger zu beschränken. Momentan sprechen sie ihn ja wie einen normalen Server im gleichen Netz an und erwarten daher von ihm auch gewisse Reaktionszeiten und eine gewisse Bandbreite.

Für den Zugriff auf andere Dateien würde man dann einen Branche Cache Server je Standort aufsetzen.

Je nach dem wie das VPN aktuell realisiert ist gäbe es da eventuell noch ein par weitere Optimierungsmöglichkeiten.

Grundsätzlich sehe ich es in solchen Situationen allerdings als sinnvoller an wenn die Mitarbeiter via RDP oder einem optimierten RDP Protokoll in der Zentrale arbeiten.

Das ganze Thema wirklich zu besprechen würde allerdings locker mal einen Tag füllen, allein für eine Bestandsaufnahme und Analyse der Ist-Situation ginge sicher ein halber Tag, wenn nicht mehr drauf, in der restlichen Zeit könnte man gerade noch grob ein Konzept und Handlungsanweisungen skizzieren.
Das wäre dann doch ein wenig viel für ein Forum wie dieses hier...

Also ich kann es zwar provozieren das der David Client einfriert und sogar dessen Fenster dann nicht mehr richtig dargestellt wird, aber ich kann es nicht ansatzweise reproduzieren das dann das Windows nicht mehr reagiert.

Wenn ich dieses hängen das David Fensters reproduziere kann ich das David Fenster als solches in dem Moment nicht minimieren, jedenfalls nicht über dessen Controls.
Ich kann es aber mittels Desktop anzeigen zwangsweise minimieren und ich kann natürlich auch zu anderen Fenstern die ich eh schon offen habe springen, sei es über die Taskleiste oder sei es über <Alt>+<Tab>

Wenn Dein ganzes Windows bei der Aktion unbedienbar wird so das Du nicht mehr zu anderen Fenstern wechseln kannst hast Du aber meiner Meinung nach noch irgend ein anderes Problem und für mich besteht der Verdacht das dieses Problem sich durchaus auch auf das Verhalten des David Clients als solches auswirken könnte. Ich würde in solchen Fällen immer mal die Themen Antivirus und Firewall Software unter die Lupe nehmen, aber auch solche Geschichten wie irgendwelche Netzwerkoptimierer oder dergleichen, wie man sie sich gerne auch mal mit Webinar Viewer Software einfängt. Ich habe da durchaus schon kurioses Zeug auf BYOD Rechnern von unseren Mitarbeitern vorgefunden und das ein oder andere aufzuräumen gehabt wenn Kollegen statt einem Rechner von uns ihre eigenen Notebooks zum arbeiten verwenden wollten, aber letztlich habe ich noch alle Kisten so zum stabil und flüssig arbeiten bekommen als das ich keine regelmäßigen Beschwerden über Unbenutzbarkeit von David im mobilen Betrieb zu hören bekomme. Natürlich gibt es das immer mal das die Kollegen kein sinnvolles Internet haben aber dennoch irgendwie arbeiten müssen, das ist dann aber halt schlicht nicht die Schuld vom David und es tritt eben nur vereinzelt auf.

Um das hängen des Fenster wie von dir angegeben mit dem Quickfinder zu provozieren muss ich allerdings die Netzwerkbandbreite recht drastisch reduzieren, oder die Latenz künstlich erhöhen, oder per schlechter Internetverbindung wie z.B. UMTS auf den David Server zugreifen.

Dieses Vehalten habe ich ab und an auch lokal. Es sieht so aus als ob das David Fenster alles blockiert. Abhilfe schaft nur den Taskmanager per Tastaturbefehl zu öffnen und David zu beenden. Das sieht dann so aus als würde das komplette Windows nicht mehr reagieren, tatsächlich liegt es aber nur an David.

Probiere folgendes: Schalte in den Optionen unter Einstellungen - Ansicht - Einstragsliste die Unterstützung für lange Betreffs aus. Du kannst dann zwar keine langen Betreffs mehr anzeigen und auch nicht mehr komplett darin suchen, die Suche reagiert dann aber wieder sehr viel schneller (speziell beim mobilen Client). Und dann solltest Du überall die Kommentarspalte in der Ansicht Deiner Ordner ausblenden, denn das beschleunigt den Zugriff auf die Archive ebenfalls deutlich. Danach kannst Du auch bei knapper Bandbreite oder langsamen Server i.d.R. normal mit Deinem mobilen Infocenter arbeiten.

Die Darstellung und Suche in Feldern, die langen Text erlauben, ist im DAVID-Client bei mobiler Nutzung ätzend langsam. Wenn man die Suche verwendet und die o.a. Felder/Funktionen aktiviert sind, dann sollte man in jedem Fall warten, bis das Suchergebnis angezeigt wird, bevor man irgend etwas anderes anklickt. Sonst hängt der Client mit blauem Kreisel und man kann ihn nur noch mit dem Taskmanager abschiessen.

TOBIT müsste hier dringend etwas tun, kann das aber vermutlich prinzipbedingt nicht. Die Suche in großen SQL-Binärfeldern dauert einfach lange, weil hier nichts indiziert werden kann und beim Darstellen dieser Felder in der Ansicht (Kommentarfeld) wird offenbar immer die gesamte Datenmenge vorab zwischen Server und Client bewegt und das dauert bei mobiler Nutzung ebenfalls sehr viel länger, als wenn man das Ganze im Büro mit z.B. Gigabit-Netzwerkanbindung macht.