[DGD] Changing connect() (network package)

[bart at wotf.org]

So.. you did talk me into giving this a try somehow.. :)

I got rid of the object destruction bug I was having (I think at least.. ) and
moved to 1.2.130

http://mud.wotf.org/dgd-130-netpatch.tar.gz

Its a driver patch only, you'll have to modify the kernel to support it
probably. Sorry, I use my own kernel, so no kernel patches from me.

I have not tested it much, but a first try with my own kernel gives a working
environment that I can login to, and that is making the outgoing connections
it should.

Hope it is of use to anyone, but be aware that this is really a quick hack
job, if it works for you all the better, if not, well.. send me patches or
make something better! :)

Bart.

On Sun, 9 Dec 2007 17:51:40 +0100, Petter Nyström wrote
> While you are familiarizing yourself with the network code, you 
> should re-write it to work with the latest branch of DGD! I know I 
> am not the only one that would be interested in playing with it then.
> 
> As for your solutions, they sound solid for as little as I know.
> 
> Cheers,
> 
> Jimorie
> 
> On Dec 9, 2007 5:00 PM,  <bart at wotf.org> wrote:
> > As mentioned in my previous mails, I've been changing the network package to
> > make calls to connect() non blocking.
> >
> > I got it to work as I want, that is, connections are made without freezing the
> > mud untill the initial 3 way handshake is complete, and the calling of open()
> > is delayed untill the connection has been made, and is not called at all when
> > no connection could be made. Also, conn_read and conn_write have been changed
> > to not error on connections that are awaiting completion of the initial
handshake.
> >
> > When the connection fails, I want to report that back to the object that
> > called connect() by means of a callback. I see a few ways of doing this:
> >
> > 1. Call receive_message() with an appropriate string (strerror or alternative)
> > and let the object figure out it was an error from the fact that open() was
> > never called and hence there was no connection to receive data from.
> >
> > 2. Call an alternative function, ie: receive_error() with the failure message.
> >
> > 3. Call open() with an argument to indicate the failure.
> >
> > I don't like 3 really, but unsettled on 1 and 2. I'm using option 2 for
> > testing the code and this seems to work well.
> >
> > Any opinions on this? Or for that matter, anyone else interested in this?
> >
> > Bart.
> >
> > ps: testing and debugging it still, when satisfied I'll make this patch
available.
> > --
> > Created with Open WebMail at http://www.bartsplace.net/
> > Read my weblog at http://soapbox.bartsplace.net/
> >
> > ___________________________________________
> > 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/