[DGD] Writing an external network daemon

[Noah Gibbs]

  It's pretty much raw TCP/IP.  Telnet is a protocol overlaid on top of it, as is UDP.  Binary is the basic TCP socket connection.

--- On Mon, 7/27/09, Blake Arnold <BArnold at cartonservice.com> wrote:

> From: Blake Arnold <BArnold at cartonservice.com>
> Subject: [DGD]  Writing an external network daemon
> To: "All about Dworkin's Game Driver" <dgd at dworkin.nl>
> Date: Monday, July 27, 2009, 8:57 AM
> 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
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>