Get Blogged by JoKi

"The only frontiers are in your mind"
22 | 07 | 2017
Navigation
Syndication
Latest Tweets

Most Read Articles
Article Time Line
About me
Family guy, geek, entrepreneur, software craftsman: Visual FoxPro, C#, SQL Server, MySQL, Linux consultant, conference speaker

Certificates & Awards

Microsoft Certified Professional

Microsoft Specialist - Programming in HTML5 with JavaScript and CSS3 Specialist

Get in touch

Sharing is caring

Recent books


Sponsoring
If you like the information on these pages, your support is highly appreciated.
Thank you very much!
Affiliates

 

Spacer for layout formatting

Bauen wir uns einen Webserver

User Rating:★★★★★ / 1
PoorBest 
Development 26 March 2006 - 

Ausgehend von zwei konkreten Vorlagen (Buch mit Codesnipplet und Eeva) ergab sich direkt die Möglichkeit zur Erstellung eines lokalen Webservers. Dieser wird sozusagen "afp-enabled" gebaut. Dies ermöglicht es uns, dass wir autark ohne externen Webserver arbeiten können. Mögliche Anwendungsszenarien sind hierbei die Auslieferung auf CD und vorallem zum vereinfachten Entwickeln und Debuggen.

Die aktuelle Implementierung basiert auf dem Microsoft Winsock2 ActiveX Control. Dieses hat jedoch nach MSKB und einigen Onlinebeiträgen kleinere Bugs und die Limitierung auf 5 concurrent Connections. Naja, nicht weiter brutal, da man jederzeit eine andere Socketimplementierung drunter setzen könnte.

Die nächste Ausbaustufe wird die Implementierung des Webservers in .NET 1.1 und 2.0 sein. Hier liegt der rudimentäre Code in C# bereits vor. Der Ansatz basiert auf der Verwendung der System.Net.Sockets.TcpListener Klasse in Verbindung mit System.Threading - schliesslich soll der Server ja mehrere Clients zeitgleich bedienen können. Naja, eventuell gönne ich mir mal einen Blick in den QUellcode von Cassini bzw. XSP. Hier könnten sich potentiell noch Anregungen ergeben, wie man auch gleich ASP.NET integriert und per Factory Pattern sowie Plugins weitere Extension anbinden könnte... Naja, mal sehen, wie weit wir den Spass treiben wollen.

Aktuell bereitet mir die Konfiguration und die sonstigen Information wie Mimetypes, Logging, Fehlercodes und anderes ein wenig Kopfzerbrechen. Aber auch hier werden sich sicherlich coole Möglichkeiten finden. Und wenn's "nur" der Zugriff über Ole DB auf VFP Tabellen ist. Hm, dürfte wahrscheinlich die einfachste Lösung darstellen. Dadurch können beide Server (VFP und .NET) *hüstel* alle drei Server, über die identische Konfiguration und sonstigem Beiwerk gefahren werden. Spart mir Nerven und Zeit. Potentiell kann man sogar partitionieren, so dass multiple Instanzen möglich sind. Evtl. sogar mit der Option, dass sich der Webserver seinen Port selbständig im unpriviligierten Bereich sucht und bindet. Hierbei würden wir dann lediglich den letzten aktiven Port pro Implementierung irgendwo ablegen. Dies verkürzt im Normalfall den Startprozess.

[code comment="Portselektion beim Serverstart"]Start der Anwendung
Konfig einlesen (Port, etc)
Port prüfen
- wenn bound, Schleife mit Randomport laufen lassen
- neuen Port sichern
Ausführung[/code]

Die zentrale Konfiguration könnte man entweder als DBF und/oder XML ablegen. Wahrscheinlich dürfte es am einfachsten für beide Systeme sein, wenn man eine XML-Datei eines DataSet / XmlAdapter verwendet. Nativer Zugriff auf beiden Seiten... mal testen.

Weitere Features? Aktuell noch keinen Plan...


Bis denne, JoKi


blog comments powered by Disqus
 
Spacer for layout formatting