Netzwerkkommunikation
Hallo,
ich habe eine Anwendung, die auf verschiedene PCs verteilt in verschiedenen MOdi laufen wird und über das Netzwerk kommunizieren muss.
Prinzipiell sollen über das Netzwerk nur Commands abgesetzt werden an den entsperchenden Modi und dieser soll dann reagieren.
Ich hatte das ganze schonmal mit TCP/IP umgesetzt. Leider laufen die SOckets nicht so stabil unter Vista. Nach einigen Stunden bricht immer einfach die Kommunikation ab, ohne ersichtlichen Grund. Nachdem ich das per UDP versucht habe lief es etwas länger, aber das Socket Problem bleibt. Habe das Gefühl das da intern im .NET ein Puffer vollläuft und dann keine Sockets mehr generiert werden können.
Nunja, nun möchte ich das etwas eleganter lösen. Dabei habe ich mir überlegt eine HTTP Kommunikation zu machen. Einen kleinen WebServer zu programmieren, der auf bestimmte commands lauscht und eben einen WebClient der dann commands absetzt. Hier hätte ich ohne Probleme immer eine Request/Response Technik und bislang funktioniert das in meiner Testanwendung reibungslos auch über Tage.
Was haltet ihr von dieser Art Kommunikation und macht das Sinn für eine solche Anwendung?
Grüße
ViperNeo
das problem sollte dann aber bleiben, weil es auch TCP ist.
Nur das protokol ist ein anderes. Denk mal drüber nach! 😃
Ich nutze aber den HTTP.SYS von Microsoft. IIS Server. Dieser im .NET eingebunden funktioniert perfekt und ohne Probleme.
Klar ist es auch TCP aber das hat doch nichts mehr mit den SOcket Klassen von Microsoft zu tun.
Bekommst du eine Exception, oder was passiert? UDP ist ein verbindungsloses Protokoll, kann also nicht die Verbindung verlieren. Erstelltst du jedesmal einen neuen Socket, wenn du etwas schickst? Schließt du die Sockets nach dem senden wieder?
Gruß
Dario
Klar ist es auch TCP aber das hat doch nichts mehr mit den SOcket Klassen von Microsoft zu tun.
IIS ist auch von microsoft... windows glaub ich auch.
Klar ist es auch TCP aber das hat doch nichts mehr mit den SOcket Klassen von Microsoft zu tun.
IIS ist auch von microsoft... windows glaub ich auch.
Die Frage ist ja, ob der IIS in .Net implementiert ist. Windows jedenfalls nicht 😉. Aber ich hatte bisher noch keine Probleme mit Sockets.
der unterschied liegt einfach nur darin, dass eine HTTP verbindung ja nicht immer offen ist.
ich tippe auch drauf, dass versucht wird, bei einem verbindungsabbruch, den alten socket zu restaurieren, was aber nicht möglich ist. sondern man muss einen neuen socket erzeugen (oder einen neuen tpcclient).
oder einfach den heartbeat einbauen, wie in dem anderen thread schon erwähnt...
und ohne code, kann man eh nur ins blaue raten.
Was haltet ihr von dieser Art Kommunikation und macht das Sinn für eine solche Anwendung?
Ich halte davon garnichts! Warum einen eigenen Webserver schreiben? Das ist Quatsch. Der IIS hat hervorragende .NET-Unterstützung und ist sehr leistungsfähig und zuverlässig (Seit Version 6.0).
Mit WCF hast Du ein fertiges Kommunikations-Framework, an dessen Qualität und Leistung Dein selbstgebasteltes vermutlich nicht mal annähernd ranscnuppern kann. Warum dann viel Zeit und Mühe investieren, um Infrastruktur-Code für die Kommunikation zu schreiben? Steck Deine Enerieg lieber in die Lösung des eigentlichen fachlichen Problems, statt ein 968sten Mini-Webserver und die 45671ste RPC-Implementierung selber zu basteln.
WCF ist nicht schwer zu erlernen (wenn man sich auf die - für das aktuelle Projekt relevanten Funktionen - beschränkt). Außerdem ist es komfortabel, schnell und flexiebel. Den IIS brauchst Du dazu auch nicht. WCF ermöglicht mit Self Hosting das Hosten von Services in beliebigen .NET-Anwendungen (z.B. einem Windows-Dienst).