Best windows Client Server lib

[Unknown W. Brackets]

Heh, this is very related to my work... not to mention I write HTTP and 
FTP protocol implementations for fun...

It sounds like reusing HTTP for communication wouldn't be a bad thing 
for you.  With it, you would see the following benefits:

1. Standardized, so adding clients should be fairly easy.
2. Provides easy ways to use encryption (SSL.)
3. Fairly efficient (keep alive, chunked, etc.) assuming you use HTTP/1.1.
4. Supports caching and should (depending on your actual data storage.) 
ease scaling concerns should you worry about them.

Depending on your needs, I would suggest writing either a simple CGI or 
fast-cgi script to respond to http requests.  Writing a module for a 
webserver (ISAPI or Apache, for example) is also possible, and somewhat 
more efficient in cases, but also much harder with D.

http://en.wikipedia.org/wiki/CGI
http://en.wikipedia.org/wiki/FastCGI (shows D implementation available.)

Unless you need a more persistent interface (with constant 
communication, messages originating spontaneously from the server, etc.) 
this will be much easier, more maintainable, and future-proof.  IMHO. 
Essentially, KISS.

FastCGI and CGI work with IIS, Apache, lighttpd, and many other webservers.

-[Unknown]


janderson wrote:
> Unknown W. Brackets wrote:
>> I think it sounds like what you want could simply use FTP as a 
>> backend, or even DAV.  Mail is most likely the completely wrong way to 
>> do it...
>>
>> In fact you basically seem to be describing FTP (user asks 
>> for/sends... reply... etc.)  FTP, of course, is a bit slow (which is 
>> why Subversion, also similar in ways to what you describe, is 
>> implemented using DAV.)
> 
> It should be very similar to Subversion.  Actually subversion may be 
> used as a backend (ie to store history and stuff but no direct interface 
> to the user).
> 
>>
>> Some questions to help narrow down your search:
>>
>> Would all your clients be Windows?
> 
> To begin with yes.  In the long run I'd like to make it portable.
> 
>> Would your server also be Windows?
> 
> Yes.
> 
>> Do all clients only talk with the server, or with each other?
> 
> Just to the server.  Server, Client not peer to peer.
> 
>> Do they relay things through the server, or just store things that 
>> other clients will then ask about?
> 
> 
> 
>> Do you have any plans/desires for being able to scale the solution to 
>> more than a single server?
> 
> Eventually but not in the beginning.  I imagine it would need to support 
> about 100 users, maybe 10 at a time.
> 
>> Do you need security/certificates/encryption?
> 
> Yeah, mainly for passwords so I can't see them, although encrypting all 
> the data would probably be useful.
> 
>> Does the server actually need special logic, or is it a bucket?
> 
> The server will have some special logic, like special access privilages 
> for users and stats tracking.  Basically I need to monitor and control 
> every request the user makes and its a dynamic thing (ie a users 
> privileges can change based on things they do).  I also may eventually 
> add things like chat down the road.
> 
> Great questions BTW.
> 
>>
>> I've actually taken part in writing an FTP server, and had a data 
>> communication server (it's used for multiplayer games and chat and 
>> stuff) contracted using D, but those were both simply using sockets. 
>> FWIW, if you decide to extend Phobos' Socket I strongly suggest 
>> recompiling Phobos as a debug build.  There are gotchas.
>>
>> -[Unknown]
> 
> Thanks.