April 09, 2008
Koroskin Denis wrote:
> Take a look into RakNet. Great library and it's already ported to D (http://team0xf.com/index.php?n=Site.Download)

Cheers, this network lib looks great.  It will definitely be high in my list of considerations.

Cheers.

-Joel


> 
> On Tue, 08 Apr 2008 06:46:44 +0400, janderson <askme@me.com> wrote:
> 
>> lurker wrote:
>>> i use it myself, is need and fast.
>>>              http://prostoserver.com/
>>>   for crypto i use
>>>            http://www.cryptosys.net/pki/index.html -- super!!!
>>>   hope it helps.
>>
>>
>> Cheers I'll look into these, although I'd prefer something that's already been ported to D.
>>
>> -Joel
>>
>>>    janderson Wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm looking for a good network library for a project I'm considering starting.  Basically I need to be able to handle multiple users who would login then send messages and files back and forth with the server.
>>>>
>>>> Has anyone done that?  What libraries are you using?  Anyone have any examples of performing the basic login procedure. I'd rather not start from scratch.
>>>>
>>>> Cheers,
>>>> -Joel
>>>
> 
April 09, 2008
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.
April 09, 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.
April 09, 2008
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.

And, people from behind a firewall can use it.
1 2
Next ›   Last »