[DGD] networking/beginner comments

Shentino shentino at gmail.com
Sat Jul 25 04:15:53 CEST 2009


I haven't figured out how to do so yet, but apparently using the LPCSSH
package can provide ALMOST foolproof networking functionality with vanilla
DGD.

For me, the tricky part is having the external daemon properly authenticate
itself to the LPC layer.

A daemon though would be the ultimate in forward compatibility.  Felix
remains opposed to any official networking support in the driver itself.
>From what I gather, the subject has been the source of many debates and
flame wars, so I'd consider it verboten territory to venture into detail
about.

On Fri, Jul 24, 2009 at 5:06 PM, <bart at wotf.org> wrote:

> On Fri, 24 Jul 2009 13:35:56 -0700 (PDT), Noah Gibbs wrote
> > Yes, that could be done.  There was talk (but no action) awhile
> > back about the idea of having an external server that allowed
> > outgoing network connections with vanilla DGD, for instance.  But I
> > think the consensus was that you're better off just using DGD
> > patched with the network package.
>
> My obviously biased opinion is that it is the fastest way.. but rather
> incompatible with dgdmp :)
>
>
> >
> >   If you *do* use the network package, you could get the protocol
> > you describe entirely at the LPC level rather than needing an
> > external server.  So then the question is what does the protocol do
> > and how does it look?  Having an inter-DGD protocol is reasonable,
> > but you'd have to figure out some use for it before people are
> > likely to spend time building it :-)
>
> It quite depends on what you want indeed.
>
> I use a protocol based on what is in use on the intermud 3 network to
> synchronize things like mail between copies of my mud, and it is very easy
> to
> extend that to other things that involve the exchange of lpc data between
> different instances of dgd. Doing something useful with that is an entirely
> different matter.
>
> Bart.
>
>
>
> >
> > --- On Fri, 7/24/09, Blake Arnold <BArnold at cartonservice.com> wrote:
> >
> > > From: Blake Arnold <BArnold at cartonservice.com>
> > > Subject: [DGD] networking/beginner comments
> > > To: "'dgd at dworkin.nl'" <dgd at dworkin.nl>
> > > Date: Friday, July 24, 2009, 11:59 AM
> > > Hello, since this is my first post
> > > here I would like to say HI! So now that that is over please
> > > excuse my stupidity on some topics, I am still a beginner on
> > > a lot of them.
> > >
> > > From what I have read so far on attempts to extend the DGD
> > > driver's networking functionality the approach is always to
> > > edit the DGD code to include this functionality. It may be
> > > the fastest route to accomplish the same end result however
> > > I fail to see the need to take this route.  Has anyone
> > > ever attempted to use the existing DGD functionality to
> > > build a communication layer above the DGD driver that is
> > > capable of communication between multiple DGD processes'?
> > > Essentially creating a non-verbose (high-level)
> > > communications language. To top it off the communication
> > > would be Object Oriented would it not?(if done properly),
> > > Does that mean that our created communication layer is also
> > > independent from the underlying layers (in the idea that as
> > > long as the 'communication' that is received is the same
> > > that was sent, it's irrelevant how it got from one point to
> > > the other).
> > >
> > > And that will finish off my rambling. I'm interested to see
> > > what other opinions are on the topic. Anyway I see the DGD
> > > driver and the kernel lib as a very nice piece of work my
> > > kudo's go to the creators.
> > >
> > > BA
> > > ___________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >
> >
> > ___________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
>
>
> --
> Created with Open WebMail at http://www.bartsplace.net/
> Read my weblog at http://soapbox.bartsplace.net/
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list