[DGD] Writing an external network daemon

[bart at wotf.org]

On Mon, 27 Jul 2009 17:28:47 +0200, Felix A. Croes wrote
> bart at wotf.org wrote:
> 
> > Please note that the network package changes udp behavior quite a bit. My
> > answer concerns the network package.
> 
> This may be a good moment to recapitulate how UDP is handled by
> vanilla DGD.

I was hoping you would, thanks :) 

I want to emulate the behavior of 'vanilla DGD' in the kernel lib for the
network package as close as possible so that non kernel code should work with
little to no changes.

> 
> UDP is only supported as an addition to an existing (binary) connection;
> it functions as a kind of out-of-band channel and communicates with the
> same connection object.  On the server side, the UDP port is the 
> same as the TCP port; on the client side, the ports can be different.

Does it accept udp packets from other ips then the one that it has a binary
connection with?

> 
> UDP has to be explicitly enabled for each connection.  This is done 
> by setting a datagram challenge for the connection object with 
> datagram_challenge().  The challenge is a string that the client has 
> to send as an UDP packet.  UDP packets sent by the client before a 
> challenge is set are ignored; UDP packets which do not match the 
> challenge are also ignored.  The purpose of the challenge is threefold.
> First, it prevents the sending of UDP packets from the server to arbirary
> destinations.  Second, it identifies the client, and the UDP port on
> which it communicates, to the server.  And third, it can establish a
> route through a firewall that the client may be behind, which the
> server can follow back.
> 
> Once the datagram challenge packet has been received, open_datagram()
> is called in the connection object, and thereafter the connection
> object may use send_datagram() to send UDP packets to the client.
> Packets to the server are received by the function receive_datagram()
> in the connection object.  The challenge itself is not received by 
> the connection object.

open_datagram() doesn't take any arguments so I assume the client port is
known internally, but not exposed to the lpc layer? (its not really needed
there at any rate for all I can tell, tho it might be desirable to know I can
imagine)

> 
> UDP packets are passed on to the connection object as they are
> received.  DGD makes no attempt at packet reassembly or preventing
> out-of-order reception.  Only one UDP packet can be sent by each
> connection object per execution round.

This also applies to the network package, but it extends this with a
datagram_done() callback similar to message_done() for telnet and binary tcp
connections to make buffering in lpc easy and similar to tcp buffering.

> 
> Closing the TCP connection will also close the UDP channel.
> 
> Regards,
> Felix Croes
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/