Hi Doug,
> There has been no formal proposal or work done in this area. If you or
> anyone is interested, I can help.
I'd appreciate your help. I think that server socket support could be a
useful extension to the existing necko.
In my opinion the best way to implement this support is to extend the
nsISocketTransport interface with new function called e.g.
"asyncAccept". This function could take the following parameters:
1) a string containing hostname to bind to (could be "0.0.0.0" to bind
to any address)
2) a port number to bind to
3) a backlog value needed for PR_Listen
4) an pointer to a listener interface receiving the accepted socket (I
don't know if there is already an existing interface that fits ours
need, if not we'll have to create a new one)
5) a context interface pointer as used by the nsITranpsort::async????
functions
6) proxying flags for the listener interface as used by the
nsITransport::async???? functions
Calling this function could lead into creating a new socket, binding it
to the specified address and calling PR_Listen. Afterwards the socket
would be added to the work queue of the socket transport service. As
soon as a connection attempt is detected, the PR_Poll would return with
a read event for the server socket. The nsSocketTransport's Process()
would create a new nsSocketTransport object and assign the accepted
socket's file descriptor to this object. So far, so good...
The big question for me (being a newbie working on mozilla since one
week :-) is whether I am allowed to extend the nsISocketTransport
interface. I tried implementing server sockets as a socket provider
service in the first place, but realized very soon, that this is not the
right place, since I cannot assign the accepted socket to a
nsSocketTransport object without making modifications there.
Any discussion about this proposal is welcome...
Daniel
