[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[HLL] Protokoll

Status: RO
Content-Length: 3241
Lines: 78


Hi all_you_out_there !

> 1. It should be extensible, so there should be some real 'option
> negotiation' during protocol setup.

Really a good idea, imho !

Is it always clear what scheme to use, if you can choose ?

What if both stations support i.e. multiple compression-rates ?
Would you choose better compression or better quality ???
One person would choose good_quality/high_data-rate because
they like good voice-quality. Someone else might prefer a
lower rate to reduce costs or have bandwith to send other
information as well. The same problem also arises if you can
select between sereral encryption-scheems. What should we use ?

Those choices might need user-interaction (at least setting some
default-policies in advance). Fixed rules might not be enough.

However we should not bore about these questions too much for now.
Our (first) goal should be to support *one* method for each task
(compression/encryption). This means the device offers one mode
and only accepts connections using this mode. This is compatible...

> 3. I don't think we would want a 'reliable' (like TCP) connection
> protocol.

Usually it makes no sense to re-transmit audio-info, simply because
there is typically no bandwidth left to do it in time.

My current understanding of the subject is:
If the receiver splits (decrypted) received frames into control-info and
data-channels, it can directly retrieve audio-information for 20mSec.
This audio-info is then simply put into a "fifo", spooling audio-output.
If a frame is trashed or lost, this will simply not generate a new
audio-info for the fifo. This will lead to either reducing the len of
the fifo (by simply skipping those 20mSec in audio-output) if the fifo
does not run empty - or to 20mSec of silence if it does run empty.
I feel that this should be ok, and it pushes all related software into
low levels of the kernel - making those loops short and optimizable !

Control-Info taken from frames is not protected on this level.
Any missing frame might lead to missing control-informations.
But - thats no problem:  ;-)
Most of those control-info is dedicated to information about current
bandwidth/channel-allocations in that frame. This info is valid only
for the current frame - so if you loose it you won't need information
about its structure as well.
A smaller part of this control-info is used to send complex commands.
They can be of different length and their transmission may split over
several frames. But any communication-error for those commands will
be detected (and the command re-tried), because executing this command
uses checksums and bidirektional handshake.

Have a nice time !


P.S. If someone is interested in the circuit-diagram for the
     hardware-csprng, it's on the net:

Version: 2.6.3i
Charset: latin1