Probleme mit dem internationalen sowie dem mobilen Arbeiten mit David

    Hallo!

    unser Unternehmen nutzt David Tobit seit 20 Jahren. Wir sind schön gewachsen und haben mittlerweile 15 Filialen auf der Welt, in Asien, Europa, USA.

    Da die Latenzen groß sind, haben wir auf drei Kontinenten jeweils einen David Server mit den lokalen Usern. Diese David Server replizieren sich gegenseitig.

    Auf unseren Servern befinden sich neben den Benutzerkonten auch einen für alle Mitarbeiter weltweit zugängliche Dokumentenbasis, die sich täglich erweitert. Das funktioniert mit David einfach super und das möchten wir auch nicht mehr missen.

    Probleme gibt es aber einige und je weiter wir wachsen, desto mehr Beschwerden folgen.

    Die zwei kritischsten Punkte nenne ich mal:

    1) Ist ein Büro oder ein User nicht direkt per Netzwerkkabel an einem der Server dran, sondern muss über das Internet zugreifen (z.B. das Büro Singapur geht an den Server in Hong Kong, oder der Außendienstler sitzt mit Laptop im Zug und schreibt Mails), dann gibt es zwei Möglichkeiten Tobit zu benutzen, die beide schwierig sind:

    - man benutzt den Client bzw RDP. Beim Schreiben einer eMail im Editor wird nun leider jeder einzelne Tastendruck per Internet zum Server übertragen und der getippte Buchstabe erst dann auf dem Bildschirm angezeigt, wenn der Server auf der anderen Seite bestätigt.

    Will heißen: Wenn das Internet etwas Latenz hat - bei langsamer Verbindung oder großer Entfertnung zum Server - oder das Internet mal für ein paar Sekunden weg ist - z.B. im Zug oder Auto), dann ist das Tippen einer eMail eine wahre Qual, denn der Cursor bleibt einfach stehen.

    - oder man benutzt den lokalen Client mit Replizierung. Damit ist zwar die Nutzung des Editors auch bei Latenzen und Internet Ausfällen möglich, aber damit hat der Benutzer auch alle replizierten Ordner lokal auf seinen Rechner kopiert. Gleichzeitig kommt der Benutzer an etliche andere Ordner (z.B. unsere Dokument-Datenbank oder alte eMail Archive) nicht mehr heran, obwohl er doch eigentlich eine Internet-Verbindung hätte. Man kann ja schließlich nicht den gesamten Server auf's Laptop replizieren

    Die gesuchte Lösung:

    Eigentlich will man doch den kompletten Tobit mit allen auf dem Server gespeicherten Daten online benutzen, gleichzeitig aber bitte auch bei instabiler oder langsamer Verbindung eine eMail eintippen können, ohne dass dabei gleich der Cursor stehen bleibt, denn das NERVT!

    Gibt es dafür eine Lösung? Kann man den Editor irgendwie dazu bringen unabhängig vom Internet das Bearbeiten einer Mail zu erlauben und erst beim Anklicken von SEND die Mail zu übertragen, aber ohne gleich alles auf Replikationsmodus umzustellen?

    2) Unsere internationalen Außendienstler beschweren sich, dass man im Kalender nicht die Zeiten für Termine nach "UTC + Offset" eingeben kann. Die Kollegen sind mit Ihrem deutschen Laptop z.B. in Asien unterwegs, verbinden sich aber mit dem Server in Deutschland, der natürlich nur Termine in deutscher Zeit kennt. Oder sie tragen in Deutschland ein, dass sie in USA um 15 Uhr einen Termin haben, fliegen nach USA und dort erscheint der Termin um 9 Uhr, weil es kein Feld gibt um die Zeitzone bzw UTC-Offset einzugeben.

    Gibt es hier eine Lösung?

    Gruß,

    Thorsten

    Hallo Thorsten,

    kann dir leider nicht helfen, da ich in meiner Zeit, als noch alle Kunden David einsetzten niemand wirklich im internationalen Bereich.

    Ich vermute, du hast Tobit zu dem Thema schon einmal angesprochen? Die sollten ja eigentlich solch eine Umgebung besonders unterstützen.

    Andererseits gibt es vermutlich nirgends eine Aussage darüber, ob David wirklich praktikabel international einsetzbar ist. In die Richtung wurde auch die letzten xx Jahre nicht viel verändert. Ich denke daher, dass ihr irgendwann an die Grenze von David kommen werdet (wenn nicht schon erreicht) und die Beschwerden immer mehr werden, besonders da das Unternehmen vermutlich eher wachsen als schrumpfen wird. Und von Tobit wird es vermutlich keine Anpassungen dahingehend geben, so meine persönliche Meinung.

    Wie viele Benutzer seid ihr eigentlich im David?

    LG
    Spike

    Alles was du bemängelst sind Probleme die David im Grunde schon immer hat und an denen sich seit Jahren kaum etwas verbessert hat. Wäre es meine Installation würde ich eine Migration Richtung O365 planen. Bei David hast du die Grenze des machbaren schon überschritten.

    Was man noch testen kann ist die Anbindung von externen Usern via Outlook und ActiveSync. Damit ist zumindest ein Arbeiten offline möglich. Alternativ IMAP/SMTP.

    Hi!

    wir sind weltweit etwa 100 User.

    Klar kann man auf Office 365 umsteigen, aber hat man dort nicht ähnliche Probleme, dass man weltweit replizierende Server benötigt?

    Und müssen nicht auch dort die User alle eMails lokal auf ihrem Rechner halten, um eine Mail offline editieren zu können? Oder kann man dort offline tippen, aber gleichzeitig online auf alle Archive zugreifen, während der Client "thin" bleibt?

    Wohin mit all den Dokumenten die derzeit so elegant im Direktzugriff in der Tobit-Ordnerstruktur sind?

    Gruß,

    Thorsten

    twmemphis was Du suchst geht seit geraumer Zeit wirklich gut.

    Unsere Mitarbeiter nutzen das seit mindestens 3 Jahren tagtäglich.

    Es gibt ein par wenige Voraussetzungen.

    1. der Client muss Internet mit einer halbwegs sinnvollen Bandbreite haben, ist die zu klein kann man damit weit weniger gut leben als mit einem gewissen Lag.

    2. der David Server muss so eingerichtet sein das die es eine öffentlich - oder per VPN Client - erreichbare Adresse gibt über welche die Ports 443 und 267 zum David Server durchgestellt werden.

    3. der mobile David Client wird so eingestellt das er nicht mehr repliziert, sondern sich online mit dem Server verbindet und zwar mit dessen öffentlicher Adresse.

    4. Die Teilnehmer können den David Server benutzen als würden sie im Büro arbeiten.

    Das ist bei halbwegs sinnvollen Internetverbindungen auch in akzeptabler Weise nutzbar.

    Wir haben hier einen ganzen Teil Außendienstler die das wie gesagt täglich so nutzen und seit wir das durchgängig tun habe ich keine Klagen mehr zu hören bekommen.

    Das Infocenter von extern via Port 267 zum David Server verbinden zu lassen läuft aber wirklich nur dann vernünftig wenn Bandbreite und Latenz passen. So wie er es beschreibt - User in Singapur, Server in Honkong, am besten noch via Public WiFi - da sind Probleme vorprogrammiert.

    Bei Office 365 wird nichts mehr repliziert zwischen Servern. Es gibt in dem Fall nur noch "den einen" Office 365 Server bei MS. Das FileSharing wird dann über Sharepoint gelöst. Die Outlook Clients haben ihren Datenbestand offline vorliegen.

    Unsere Mitarbeiter sind weltweit im Einsatz und unser Server steht in Deutschland.

    Die Situationen in denen das nicht funktioniert sind extrem selten und dann ist das aber auch selbsterklärend, da kannste nämlich dann auch normales Surfen schlicht vergessen.

    Im übrigen nervt die ständige Office 365 Werbung langsam, ich bin hier im David Forum weil ich Informationen rund um David suche und wo ich sie habe auch gern gebe, nicht weil ich in jedem zweiten Thread was zu Office 365 lesen will :o

    Alternativen gehören einfach zur Diskussion dazu. Besonders wenn David einfach schnell an vielen Stellen an seine Grenzen stößt, auch wenn das bei dir nicht der Fall zu sein scheint.😉

    Die Performance-Probleme beim RPD fallen mir in diesem Fall auf.
    Das ist ein sehr ungewöhnliches Phänomen.
    Ich vermute, dass die unterschiedlichen Zeiteinstellungen der drei Server dabei eine Rolle spielen.

    Denn wenn die Uhrzeiten auf den Servern nicht identisch sind, dann sind Netzwerkprobleme wie lange Antwortzeiten fast normal.

    Der Flaschenhals, der zu Problemen bei RDP-Verbindungen führt, ist meistens mangelnde Upload-Geschwindigkeit des Servers, mit dem der RPD Client verbunden ist.
    Nota bene: Bei ADSL ist die verfügbare Upload-Geschwindigkeit um den Faktor zehn kleiner als die Download-Geschwindigkeit. Also als erstes mehr Sendekapazität zur Verfügung stellen Das geht entweder durch Bündeln mehrerer Internetanschlüsse gleichzeitig oder durch Umstellung auf SHDSL (Anbeiter z.B. QSC / PLusnet). Im Einzelfall kann es auch helfen, die Leitungsqualität zu überprüfen und gegebenenfalls den Anschluss instand setzen zu lassen. Einige Bintec Router enthalten ein Prüfprogramm, mit dem ansatzweise Leitungsprobleme wie FEC- und HRC-Fehler protokolliert werden. Die sind dann im Monitoring sichtbar. Eine Leitungsprüfung mit einem speziell dafür ausgelegten Messgerät können diese einfach gestrickten Protokolle aber nicht ersetzen.

    Ein wenig Licht ins Dunkel kann schon ein vergleichender Ping-Test bringen. Dazu wird von einem entfernten Client aus zunächst eine bekannte Domain wie Google.com oder BMW.com gepingt. Anschließend folgt zum Vergleich eine Ping-Serie auf die drei Server.

    Last not least lohnt ein Check, ob nicht ein Virenscanner alle gesendeten Daten unnötigerweise überprüft. Auch das kommt als Fehlerquelle in Betracht, wenn Remotedesktop-Zugriffe so langsam sind wie beschrieben arbeitet.

    10 Mal editiert, zuletzt von Arno (13. Mai 2019 um 00:08)

    Zitat von riawie

    Unsere Mitarbeiter sind weltweit im Einsatz und unser Server steht in Deutschland.

    Die Situationen in denen das nicht funktioniert sind extrem selten und dann ist das aber auch selbsterklärend, da kannste nämlich dann auch normales Surfen schlicht vergessen.

    Im übrigen nervt die ständige Office 365 Werbung langsam, ich bin hier im David Forum weil ich Informationen rund um David suche und wo ich sie habe auch gern gebe, nicht weil ich in jedem zweiten Thread was zu Office 365 lesen will :o

    Hast hja grundsätzlich recht. Das Problem ist nur dass die Möglichkeiten zum externen Zugriff einer der größten Schwachpunkte in David sind. Und das schon lange und ohne nennenswerte Besserung. Wer mit beiden (oder noch weiteren) Varianten gearbeitet hat kommt eben schnell zu dem Schluss dass es bessere Lösungen gibt. Die meisten User hier sind Mitarbeiter in Systemhäusern die es sich nicht erlauben können nur ein Produkt zu verkaufen, gerade wenn es nicht zu den Anforderungen des Kunden passt. Deshalb hat der Hinweis auf Konkurenz Produkte schon eine gewisse Berechtigung.

    Hm, sorry, aber ich verstehe noch nicht worin hier die eigentliche Problemlösung sein soll.

    Was Du beschreibst ist doch die normale Nutzung des Online-Clients. Fällt beispielsweise während des Tippens einer eMail im Zug die Verbindung für ein paar Sekunden aus, dann bleibt auch der Cursor stehen.

    Ist der User gerade in Hong Kong, verbindet aber zum deutschen Server, dann wird auf dem Laptop des Users jeder einzelne getippte Buchstabe erst dann auf seinem Bildschirm angezeigt, wenn der Server in Deutschland den getippten Buchstaben empfangen und bestätigt hat -> fast 1 Sekunde Latenz. Und das hat wirklich nichts mit Bandbreite zu tun, denn man benötigt Bandbreite um große Datenmengen zu schieben, aber nicht um einen Tastendruck zu übertragen. Das Problem hier nennt sich "Latenz"

    Ich kann das gerne mal demonstrieren. Schreib mir bitte PN!

    Der Onlinebetrieb des Clients ist ja grundsätzlich gut und wichtig. Er ist auch sinnvoll dafür, dass die Clients "thin" sind und die User also nicht sämtliche Mails und Dokumente (= Firmengeheimnisse) lokal mit sich rum schleppen. Aber das SCHREIBEN & EDITIEREN einer eMail ist online nicht sinnhaft. Der Editor muss lokal laufen und erst beim Klicken auf SEND die Mail übertragen, nicht aber schon während des Tippens jeden einzelnen Buchstaben über den Äther jagen, denn das führt zu großem Frust.

    Selbst innerhalb Deutschlands hat man eine winzige Latenz. Mobil hat man immer wieder Verbindunspausen, auch beim Wechsel von LTE zu 3G zu Edge, etc. All das führt immer wieder zu einem schlechten "Eingabe-Gefühl" weil während des Tippens nicht direkt und sofort die Zeichen auf dem Bildschirm erscheinen. Der Editor muss also lokal laufen, sonst kriegt man das Problem nicht weg.


    Ich denke es ist technisch prinzipiell machbar, dass der Client alle Zugriffe online macht und nur der Editor im Client bei Neu/Antworten/Weiterleiten lokal arbeitet, solange bis SEND geklickt wird. Aber dafür müsste sich Tobit eine Software-Änderung einfallen lassen.

    So wie ich es verstehe, hätte man bei Outlook einen Mailabruf auf den lokalen Client-Rechner, was einer Replizierung gleich kommt. Arbeitet man online (ohne Daten auf dem lokalen Client), hätte man das gleiche Problem mit dem Editor wie auch bei David.

    Zitat von twmemphis

    Wohin mit all den Dokumenten die derzeit so elegant im Direktzugriff in der Tobit-Ordnerstruktur sind?

    O365, OneDrive, Teams - funktioniert prima (jede Software hat natürlich eigene Grenzen und Probleme).

    Neben dem enormen Aufwand für die Umstellung und die Umschulung der Kollegen braucht ihr auch neue Lösungen für Mailarchivierung und alles Weitere. So ein Umstieg ist keine Kleinigkeit und muss gut geplant werden.

    Aber ich schließe mich der Meinung der Vorredner an: ihr kommt wohl nicht drum herum ...

    Gruß Joe

    Zitat von twmemphis

    Hm, sorry, aber ich verstehe noch nicht worin hier die eigentliche Problemlösung sein soll.

    Was Du beschreibst ist doch die normale Nutzung des Online-Clients. Fällt beispielsweise während des Tippens einer eMail im Zug die Verbindung für ein paar Sekunden aus, dann bleibt auch der Cursor stehe

    Nein, da bleibt kein Cursor stehen, denn das schreiben der Nachricht passiert lokal.
    Wenn Du Deine Nachricht fertig geschrieben hast geht sie in einem rutsch über die Leitung.

    Das was Du beschreibst ist ein Verhalten was es nur bei der Webbox oder bei RDP Nutzung gibt, nicht beim David Client.

    Wenn das bei Dir doch so ausschaut läuft da irgendwas anders als bei uns.

    Kann es sein das Ihr den David Client per RDP Application präsentation benutzt?
    Das würde so ein Verhalten im David Client bei Leitungen mit Latenz oder kurzen Verbindungsunterbrechungen nämlich erklären.

    RDP oder auch der Editor in der Web Box arbeiten Zeichenorientiert, da ist Latenz die ware Pest.

    Der David Client im Remote Einsatz hingegen arbeitet genau wie Outlook in Verbindung mit einem Exchange Server Blockorientiert, bekommt und sendet also immer einen Datenblock, also eine vollständige Mail am Stück.


    Ich habe persönlich schon über Satelitenverbindungen mit dem David Client auf unserem Server in Deutschland gearbeitet, dagegen ist Hong Kong <> Deutschland geradezu latenzfrei ;) und dennoch habe ich keine Schwierigkeiten beim verfassen von Mails.
    Merken tut man die Latenz natürlich wenn man eine Mail anklickt um sie zu öffnen, das dauert dann logischer Maßen etwas länger als das reine übertragen der Datenmenge an sich, weil ja die Latenz dafür sorgt das die Anforderung verzögert am Server ankommt.

    Einmal editiert, zuletzt von riawie (13. Mai 2019 um 17:09)

    Hi Riawie,

    bist Du sicher?

    Mein Kollege erzählt mir gerade, dass es nicht nur der Cursor, sondern die komplette Applikation ist, die immer wieder komplett stehen bleibt. Er sitzt in München und verbindet zu uns nach Bad Homburg. Da zweifle ich schon, ob es wirklich die Verbindung ist.

    Er sagte eben auch, dass er im Online-Client im Editor - wenn er nicht hängt - ohne jede spürbare Latenz tippen kann. Das würde Deiner Aussage entsprechen, dass der Editor lokal läuft. Aber woher kommen dann die "Hänger"?

    WIr haben parallel die Frage an Tobit gestellt und dort speziell auf die Nutzung im Zug angespielt. Siehe unten die Antwort. Wenn der Editor des Online-Client lokal liefe, dann würde Tobit doch nicht so antworten, oder?

    Beschreibung des Problems:

    Hallo, wir haben das Problem bei mobilen Mitarbeitern, dass sie während eines Business-Trips (z.B. im ICE) mit dem Online-Client keine Emails schreiben können, da die Verbindung weg fliegt oder gar nicht besteht. Mit dem Offline-Client gibt es das Problem natürlich nicht, aber es ist nicht gewünscht, dass der Mitarbeiter sämtliche Daten auf seinem Endgerät hat. Optimal wäre eine Möglichkeit den Online-Client zu verwenden, aber wenn man eine Email verfasst, das Fenster im Offline-Modus zu halten, dann müsste man nicht mehr auf den Roundtrip warten und die Latenz wäre umgangen.


    Antwort von Tobit:

    Diese Möglichkeit besteht nicht. Viele Grüße, Stefan von Tobit Software.


    Jetzt kapiere ich nix mehr. Lokaler Editor oder nicht? Warum geht es bei Euch, aber bei uns hängt es?

    Wollen wir mal telefonieren?

    Zitat von twmemphis

    Optimal wäre eine Möglichkeit den Online-Client zu verwenden, aber wenn man eine Email verfasst, das Fenster im Offline-Modus zu halten, dann müsste man nicht mehr auf den Roundtrip warten und die Latenz wäre umgangen.


    Antwort von Tobit:

    Diese Möglichkeit besteht nicht. Viele Grüße, Stefan von Tobit Software.

    Ich denke, man wird Euch dort falsch verstanden haben und Online Client als Webbox Zugriff aufgefasst haben ;)


    Das Problem bei solcher Kommunikation sind wohl immer die Begrifflichkeiten ;)

    Was die sonstigen Hänger angeht...

    Die kommen immer dann vor wenn der Client gerade aufgrund irgendeiner Aktion eine Antwort vom Server braucht, der aber nicht rechtzeitig antwortet, dann hakt es mal kurz und danach geht es weiter.
    Die meisten sind dazu geneigt im Client einzustellen das sie ein langsames Netz haben wenn sie unterwegs sind, das klingt auch erst mal logisch, führt aber dazu das der Client in mehr einzelnen Häppchen Infos vom Server will, daher stelle ich immer ein das die Verbindung schnell ist, auch wenn das nicht den Fakten entspricht und habe somit einen flüssigeren Zugriff auf den Server.

    Wichtig ist und bleibt aber das der Server jeweils performant ans Internet angebunden ist und nicht schon durch seinen eigenen Internetanschluss massiv behindert wird.
    Auch muss er natürlich auf performanter Hardware laufen und nicht schon durch die lokalen Nutzer immer wieder an seine Grenzen gebracht werden.

    Ich denke in vielen Fällen hapert es schon dort und das führt dann zu gefrusteten Erlebnissen bei den Nutzern.
    Ob das bei euch so ist kann ich nicht beurteilen, aber bei vielen der anderen Berichte hier aus dem Forum scheint es mehr als offensichtlich so zu sein. Denn die meisten Berichte liefern ausreichend Indizien dafür das es um SOHO Installationen geht. Ich persönlich spreche von KMU mit der Tendenz das K deutlich unter den Tisch fallen zu lassen ;) Soll heißen angemessen Ressourcen bereitstellen und das ganze läuft zuverlässig.

    Zitat von riawie

    Was die sonstigen Hänger angeht...

    Die kommen immer dann vor wenn der Client gerade aufgrund irgendeiner Aktion eine Antwort vom Server braucht, der aber nicht rechtzeitig antwortet, dann hakt es mal kurz und danach geht es weiter.

    Ah, ok.

    Dann kann ich das Problem nun etwas anders benennen.

    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.

    Selbst wenn der Editor im Online-Client lokal arbeitet (was ich Dir mittlerweile zu 95%iger Sicherheit glaube :thumbup: ) dann ist das Ärgernis, dass trotzdem immer wieder diese Arbeits-Zwangspausen entstehen, weil die komplette App, und damit auch der Editor, einfrieren. Im Zug, wo die Verbindung kommt und geht wie sie will, mal langsam und mal schnell, ist es entsprechend schlimmer.
    Ergo liegt das Problem also woanders: 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.

    Nehmen wir es also als Verbesserungsvorschlag für Tobit auf.

    Ich sehe da aber noch nicht wo Outlook besser wäre. Auch dort kann man nur wahlweise komplett Online arbeiten - ohne irgendwelche Mails auf dem lokalen Rechner - und hat entsprechend auch einen Online-Editor der hängen kann, oder man synchronisiert alle Ordner auf den lokalen Rechner (Pop, Imap, Replikation).

    Zitat von riawie

    Die kommen immer dann vor wenn der Client gerade aufgrund irgendeiner Aktion eine Antwort vom Server braucht, der aber nicht rechtzeitig antwortet, dann hakt es mal kurz und danach geht es weiter.

    Das "kurz" würde ich nicht unterschreiben. Ich arbeite mit meinem Notebook 2x die Woche in einem anderen Büro und greife von dort per Direktzugriff (Port Forwarding) auf meinen Server zu. Oft vergesse ich am nächsten Tag, über Netzwerk -> Server wieder auf den LAN-Namen umzustellen, und so verbindet sich der Client "von hinten durch die Brust ins Auge" über david.[meinedomain].de quasi in mein eigenes Netz. Und das funktioniert im Prinzip auch.

    Reproduzierbar ist dann aber folgendes Verhalten: Der Client steht da und zeigt keine Fehler, aber wenn man z. B. ins Fenster klickt kommt der "Warte-Kreisel" - das passiert immer dann, wenn eine Weile keine Aktionen im Client durchgeführt wurden. Bislang war es in der Tat meist so, dass sich das Programm innerhalb von ca. 30 Sekunden wieder gefangen hat, aber dezeit (seit Rollout xxx?) muss ich den Client via Taskmanager abschießen, da geht nichts mehr. Der Neuaufruf funktioniert innerhalb weniger Sekunden (und genau das ist der Teil, den ich nicht verstehe - wenn die Kommunikation offenbar klappt, warum kann der Client sie nicht wieder aufnehmen?)

    David nervt schon lange mit diesen Abbrüchen, sehr sporadisch hatte ich das bei Kunden auch schon im LAN auf einzelnen Rechnern. Ein vernünftiger lokaler Cache und cleverere/fehlertolerantere Verbindungsstrategien wären durchaus wünschenswert.

    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" ?

    Zitat von nordtech

    Das "kurz" würde ich nicht unterschreiben. Ich arbeite mit meinem Notebook 2x die Woche in einem anderen Büro und greife von dort per Direktzugriff (Port Forwarding) auf meinen Server zu. Oft vergesse ich am nächsten Tag, über Netzwerk -> Server wieder auf den LAN-Namen umzustellen, und so verbindet sich der Client "von hinten durch die Brust ins Auge" über david.[meinedomain].de quasi in mein eigenes Netz. Und das funktioniert im Prinzip auch.


    Reproduzierbar ist dann aber folgendes Verhalten: Der Client steht da und zeigt keine Fehler, aber wenn man z. B. ins Fenster klickt kommt der "Warte-Kreisel" - das passiert immer dann, wenn eine Weile keine Aktionen im Client durchgeführt wurden. Bislang war es in der Tat meist so, dass sich das Programm innerhalb von ca. 30 Sekunden wieder gefangen hat, aber dezeit (seit Rollout xxx?) muss ich den Client via Taskmanager abschießen, da geht nichts mehr. Der Neuaufruf funktioniert innerhalb weniger Sekunden (und genau das ist der Teil, den ich nicht verstehe - wenn die Kommunikation offenbar klappt, warum kann der Client sie nicht wieder aufnehmen?)


    David nervt schon lange mit diesen Abbrüchen, sehr sporadisch hatte ich das bei Kunden auch schon im LAN auf einzelnen Rechnern. Ein vernünftiger lokaler Cache und cleverere/fehlertolerantere Verbindungsstrategien wären durchaus wünschenswert.

    Das was Du da beschreibst lässt auf ein Problem des Routers bei Euch lokal schließen.
    Sowas hatten wird früher durchaus auch.

    Inzwischen arbeiten unsere reisenden Leute seit gut 3 Jahren lokal genau wie wenn sie unterwegs sind ausschließlich über die externe Adresse unseres David Servers und ist für die Nutzer im arbeiten kein Unterschied zur lokalen Nutzung fühlbar.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden