- avoid redundant entries in sending queue
- maximum queue length
- OSD menu entry (and functionality): dht-epg scan for current channel only
- OSD: display connection state
- setup possibilities

note: while waiting in INIT_REQ_DELAY, no internal requests are evaluated


? only request updates for a couple of days (not while EPGLinger-past)
  -> how does this converge? [depends on the depth of the aggregation tree]

-------------------------------------------------------------------------------

- should completeness of responses be checked? (also to prevent repeated
  requests for non-existing data)
- send _any_ block (completeness flag)
- implement 'mode: response' entry in data messages
- reduce copying of messages (msg. -> setbuf -> ostringstream) [verify]


? remember the last n destinations for requests to reduce load (?)

? unbundle destination of data messages and the actual data block (may
  differ, e.g. in responses) ???
  datamsg: dest. extra (may differ from data [in future]) ???

? request information only for channels, registered in epg.data and where
  there already is some EPG data present [but after some time all information
  will be obsolete and deleted !] ???

?! syslog in controller only? (maybe in epgdht_interface, too?)


DOC:
   - (time_t) 0 is considered a valid block starttime
   - defines at the beginning of controller.cpp
   - MAX_RECV_MESSAGE_LENGTH in epgdht_interface.cpp
   - MAX_NO_OF_CHANNELS in vdrepg_interface.cpp
   - EPGLinger
   - define timeblock format in DHT messages (not limited to 32 (or 31) bits!)
   -> epgtypes.h

   - send queue not list of epgdata: we pick data immediately before it is sent
     (might be updated in between, furthermore it's merged with our data)

   - Channels.GetByChannelID(..., true); -> 'true' mostly used by vdr

-------------------------------------------------------------------------------

OT:
 - timer to full time in Menu->Schedules

===============================================================================

done and deprecated ones (???):

- send timestamp of topicality in all epg-data messages / tableID + versionNO
  (one for whole packet, so that obsoleted data is replaced completely ?)
- epg data representation in dht messages (channel identification?)
- time block size?
- node id of original requestor on request pass-ons?
- request information only for channels, registered in epg.data and where
  there already is some EPG data present [but after some time all information
  will be obsolete and deleted !]
- mapping: 'DHT-channelname' to channel (maybe we will want to identify
  identical channels only received differently in the future [for EPG]; e.g.
  ZDF via satellite, cable and terrestrial antenna)
