none
Clients mit Callbacks von Server

    Frage

  • Hallo zusammen

    Im Rechenzenter steht ein Server mit IIS und einem Webservice. Auf div. PC wird ein Windows-Dienst installiert, welcher über die Tapi-Schnittstelle mit einer Telefonanlage verbunden ist.

    Wenn ein Anruf reinkommt, werden die Infos an den Webservice übertragen.Vom Server aus braucht es die Möglichkeit, dass eine Benutzeraktion für das Wählen einer Telefonnummer an den entsprechenden Client geht und dann über Tapi wählt. Dazu gibt es im Client einen TcpListener und ab dem IIS wird dann darüber ein XML mit Daten dazu übertragen. Wenn also UserA einen Anruf starten möchte, wird IP/Port aus der DB ausgelesen, eine Verbindung auf den Client zu dieser IP/Port geöffnet und die Daten übertragen.

    Mit diesem Aufbau funktioniert es, der Konfigurationsaufwand dürfte/sollte aber kleiner sein. Der Admin muss für jeden Client auf der Firewall eine Regel einrichten, damit ein fest definierter Port auf den entsprechenden Client geht. Port 5000 also auf IP XXX, Port 5001 auf XXW,...

    In der Konfiguration muss festgelegt werden, welcher User auf welcher externen IP/Port erreichbar ist.

    Das würde ich jetzt gerne vereinfachen, bin mir aber über die optimale Umsetzung nicht klar. Diese Clients sind nicht nur an einem Ort sondern bei div. Kunden.

    Gibt es dazu evt. direkt schon in .NET eine Umsetzungsmöglichkeit oder ein Framework welches das übernimmt? Liesse es sich mit async Webservice umsetzen? Aktuell besteht zwischen IIS und Clients keine feste aufgebaut Verbindung sondern wird nur aufgebaut, wenn es etwas zu übertragen gibt.

    Bin um jeden Tipp dankbar.

    Gruss Christoph

    Freitag, 18. Januar 2013 22:56

Alle Antworten

  • Warum brauchst du denn Callback? Warum kann diese Information nicht in dem WebService-Aufruf als Antwort mitgeschickt werden?

    Ansonsten richte einen lokalen Server ein, welcher mit dem Server im Rechenzentrum kommuniziert, damit muss nur einmal die Firewall angepasst werden. Die lokalen Clients kommuniziern nur mit diesem lokalen Server.

    Samstag, 19. Januar 2013 10:56
  • Die Clients(.NET-Dienste) nutzen den Webservice auf dem Server, um Events(Telefon-Tapi) an den Server zu übergeben. Danach ist das schon beendet. Wenn aber ein User über die Weboberfläche einen Anruf startet, soll der Webserver auf den entsprechenden Client verbinden können und die zu wählende Nummer übergeben. Das muss "live" passieren.

    Das mit dem lokalen Server habe ich mir auch schon überlegt. Das Problem ist, dass Kunden immer weniger Server inhouse haben(was wir auch gut finden) und so uns die HW fehlt, welche immer läuft.

    Bei meiner Frage zu vb.NET Module im IIS geht es Grundsätzlich auch um dieses Projekt, da ist der Client aber der Browser mit JavaScript und dieser .NET-Dienst-Client ist zuständig für die Tapi-Anbindung. Nicht dass es da Verwirrung gibt.

    Gruss Christoph

    Samstag, 19. Januar 2013 11:16
  • hmm, ohne lokalen Server gibts keine Domäne.. du brauchst auch keine extra HW, der lokale Server ist ein relativ schlanker Windows-Service, der lediglich die Daten entgegen nimmt und dann vermittelt.
    Samstag, 19. Januar 2013 11:47
  • Das betrifft Kunden mit 1-15 Usern.  Da gibt es viele, welche keine Domäne betreiben. Betreffend HW meinte ich, weil dieser kleine Server immer laufen müsste und bei 2 Usern das schwierig wird.

    Ich überlege mir, da eine Variante umzusetzen, welche bei wenigen Usern ohne einen zentralen Server auskommen(halt FW-Einstellungen nötig werden) und beim vorhanden sein eines Servers/PC's welcher immer läuft, die seperate Servervariante zum Zuge kommt.

    Gruss Christoph

    Samstag, 19. Januar 2013 12:06
  • Hallo Christoph,

    je mehr ich von deinen Postings lese, desto weniger glaube ich, dass Du dir der Limitierungen von Webanwendungen, die normal über http gesteuert werden, bewusst bist.

    Das, was Du da machen willst, geht in ASP.NET, PHP, ... nicht. Keine Chance. Schon gar nicht mit veralteten Clients.

    Was Du eher bräuchtest, wäre ein eigener Serverdienst (der auch ruhig auf einem normalen PC laufen kann, dafür aber dauerhaft erreichbar ist), der die Steuerung übernimmt. Mit diesem nehmen die Clients Kontakt auf und halten entsprechend die Verbindung offen. Dann kann der Server auch von sich aus über die Verbindung mit dem Client kommunizieren.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 19. Januar 2013 20:08
  • Hallo Stefan

    Über http wird ja vom Client(Windows-Dienst) "nur" der Webservice auf dem Server aufgerufen. Damit holt sich der Client div. Infos aus der Datenbank ab.

    Wenn vom Server aus dem Client eine Info mitgeteilt werden soll, geschieht das auf einen TcpListener auf dem Dienst. Wenn in einer Firma 3 Leute diesen Dienst auf Ihren PCs installiert haben, müssen auf der Firewall 3 Regeln festgelegt werden, dass 3 Ports auf die definierten PCs weitergeleitet werden und das ist bei 10 Usern dann mit höherem Aufwand verbunden.

    Gruss Christoph

    Samstag, 19. Januar 2013 20:34
  • Hallo Christoph,

    ahhh. Den wichtigsten Part hast Du bisher unterschlagen (oder ich habs überlesen).

    Wenn ich das also richtig verstanden habe, ist das, was ich dir die ganze Zeit empfehle, schon vorhanden? Also eine separate Clientanwendung, die mit einer weiteren Serveranwendung (nicht im IIS) eine dauerhafte Verbindung offen hält und per TCP kommuniziert.

    Warum da aber jetzt 3 Ports weitergeleitet? werden müssen, verstehe ich nicht.

    In der Regel ist das doch so nur als Beispiel:

    Server <-> Client 1
    Server <-> Client 2
    Server <-> Client 3

    Der Client baut die Verbindung zum Server auf einem bestimmten Port auf. Der Server kann dort jetzt auch seine Antwort senden. Eine weitere Verbindung vom Server zum Client ist IMHO nicht notwendig, daher sind auch keine Firewalleinstellungen am Client zu ändern, lediglich am Server Und die auch nicht x-fach, sondern einmal.



    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 19. Januar 2013 20:51
  • Hallo Stefan

    Im Moment eben nur den halben Weg, die Clients machen Webservice-Requests und der Webserver dann über den TCPListener.

    Werde mal schauen, was alles nötig ist, damit ich den Webservice durch einen eigenen Dienst ersetzen kann. Das sollte am Anfang mit dem Webservice etwas einfacher gemacht werden, würde sich jetzt aber wohl so doch besser lösen. Gibt es halt auf dem Server einen Dienst zum installieren, dafür ist der Rest einfacher.

    Besten Dank

    Gruss Christoph

    Samstag, 19. Januar 2013 21:15
  • Hallo Christoph,

    den Webservice brauchst Du ja nicht zu entfernen, der ist ja Ok. Dein Serverdienst kann ja vom Webservice über die notwendigen Aktionen informiert werden.

    Nur sollte der Server die Verbindung zum Client nicht ondemand aufbauen, sondern der Client sollte beim Start der lokalen Anwendung eine dauerhafte Verbindung zum Server herstellen. Dann kann er darüber auch Nachrichten empfangen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Samstag, 19. Januar 2013 21:48
  • Hallo Stefan

    Wenn ich jetzt aber einen eigenen Server(Windowsdienst) umsetze, wie bekommt der Server dann die Info, was an den Client gesendet werden muss?

    Bei der aktuellen Lösung wird bei einem Request vom Browser auf den IIS die Steuerdaten an den Client(Windows-Dienst) gesendet. Es wird also gleich sofort die Daten übertragen.

    Mit einem seperaten Server-Dienst müsste dann beim Request auf den IIS dieser neue Server-Dienst die Info erhalten, was an wen gesendet werden muss.

    Was für einen Ansatz wäre da zu empfehlen?

    Gruss Christoph

    Samstag, 19. Januar 2013 22:05