Best windows Client Server lib

Unknown W. Brackets unknown at simplemachines.org
Tue Apr 8 22:20:50 PDT 2008


Sorry, I should've also mentioned -

For the client you'll want a HTTP/1.1 client library, ideally.  I 
personally hate curl, and iirc Tango isn't actually compliant with 
HTTP/1.1 (would be glad to hear this has changed.)

Still, wouldn't be too hard to find one, modify Tango if it needs it, or 
otherwise I can probably look to see if I have one I can let you use/have.

I suppose you could also use WinINET on Windows which would gain you the 
user's proxy settings, but I don't really know anything about it.

-[Unknown]


Unknown W. Brackets wrote:
> 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.



More information about the Digitalmars-d mailing list