[DGD] Writing an external network daemon

Petter Nyström jimorie at gmail.com
Sun Jul 26 16:00:47 CEST 2009


Yes, I think that's pretty much what I'm doing already. I didn't get
all of it, though.

But you don't have any thoughts on how you would control the flow
going back to receive_message() of the connected objects? (If you did,
I apologize and ask that you repeat them in simpler terms. :P)

Thanks,

Jimorie

On Sun, Jul 26, 2009 at 3:53 PM, Shentino<shentino at gmail.com> wrote:
> My guess is that you would need to handle connections asynchronously, and
> presumably the round that initiates an outbound connection is not the same
> one it will be established in.
>
> If I were to implement an external daemon, I would have it connect to a
> special port which the mudlib listens to.  It only accepts connections from
> localhost.
>
> Then, just to prevent spoofing by another user on the same machine, I do a
> challenge response on the connection to verify that it is indeed the network
> daemon talking to me.
>
> Once that's done, I use the connection as a control channel for when I wanna
> boss the daemon around, say, by having it connect.
>
> The connection itself would be relayed transparently by the daemon
> connecting out as directed, and also in to the driver, henceforth acting as
> a relay.  And again, with a challenge response to make sure the connection
> to the driver isn't spoofed.
>
> Once that was done, I would treat the connection as if it was made by the
> driver.  As far as I know, a connection is the same no matter which end is
> set up first.
>
> Multiplexing on multiple connections could presumably be done inside the
> daemon with a select or poll.
>
> At least, that's how I would do it.  I've been pondering doing so myself.  I
> do bear in mind though that I might not be the only user on the machine
> running the driver, and for that I'm still trying to think of a practically
> air tight spoof prevention.
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list