[DGD] Writing an external network daemon

[Blake Arnold]

I was just about to ask what you just explained, thanks. So this leads directly to my next question which would be how the binary connection is established. I haven't had a chance to look into the binary layer yet as I was still deciphering the UDP layer. I would guess that it is a protocol operating on the internet layer?

-----Original Message-----
From: dgd-bounces at dworkin.nl [mailto:dgd-bounces at dworkin.nl] On Behalf Of Felix A. Croes
Sent: Monday, July 27, 2009 11:29 AM
To: dgd at dworkin.nl
Subject: Re: [DGD] Writing an external network daemon

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.

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.

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.

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.

Closing the TCP connection will also close the UDP channel.

Regards,
Felix Croes
___________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd