Re: Recognising one's own messages on an anonymous broadcast channel?

On 29 Jan, 15:30, Peter Fairbrother <zenadsl6...@xxxxxxxxx> wrote:
It doesn't sound silly so much as unrealistic - if you don't mind
explaining, can you tell us why?

Absolutely. As said in the original post, clients are connected to the
system via private channels. Clients send in operations which create,
modify and delete objects in the system. All clients connected to the
system should receive the result of these operations and to make
things efficient the results are broadcast to all clients who want to
listen.

To complicate things, clients often analyse the results which are
broadcast and act upon them. Therefore, it's *very important* that a
client can recognise a result as its own so that it does not react
upon its own operations so to speak. That's the motivation behind (2)
in the original post.

Since clients are constantly analysing the results which are broadcast
and also are competing with each other, it's *very important* that one
client cannot find out who sent the operation which caused a specific
result. This is the motivation for (1).

If a client ignores a result because it thinks it was the result of
one of its own operations, it can miss information which the other
clients acts upon. This means that the client would have a different
view of the system than the other clients, which would be *very bad*.
That's the motivation behind (3).

One disadvantage would be that the clients would have to keep a record of
the nonces they issued - there are ways around this, but see below.

Yes, that's a disadvantage, but still acceptable. The best thing would
be if the client could find out its user id or similar from the
broadcast results and thus ignore the message based on that instead of
recognising a nonce.

Another possibility might be for the "trusted" server to give each message a
unique number over the private channel, and for the client to keep a record
of this number.

Yes, that would work, but the problem here is that the broadcast
result probably would reach the client before the client had received
the unique number of the private the channel. The reason for this is
that the system is quite latency sensitive so we want to avoid
delaying information unless necessary.

Given the high volume of traffic (100 kmsg/s), we want to avoid
buffering the broadcast messages in the client until the unique number
has been received on the private channel.

It sounds like you are home-brewing an anonymity protocol, which is a
mistake unless you a) have to, which is possible, and b) are expert, and
then have it reviewed.

Finding a well-tested algorithm/protocol with the properties we need
is what we're looking for - perhaps we just don't know what to search
for?

I am also slightly confused guessing why the client has to recognise the
messages he sent, with absolutely no collisions!

Hopefully, the overview above makes it clearer.

.

Relevant Pages

  • Re: Recognising ones own messages on an anonymous broadcast channel?
    ... As said in the original post, clients are connected to the system via private channels. ... All clients connected to the system should receive the result of these operations and to make things efficient the results are broadcast to all clients who want to listen. ... Since clients are constantly analysing the results which are broadcast and also are competing with each other, it's *very important* that one client cannot find out who sent the operation which caused a specific result. ... Given the high volume of traffic, we want to avoid buffering the broadcast messages in the client until the unique number has been received on the private channel. ...
    (sci.crypt)
  • Re: Recognising ones own messages on an anonymous broadcast channel?
    ... 128-bit random nonce collision happening. ... I do not know the nature of the "private channel", but it is far more likely ... client cannot find out who sent the operation which caused a specific ... the nonces they issued - there are ways around this, ...
    (sci.crypt)
  • Re: Please help with restoration project
    ... On a restoration project the first question you have ... > to ask yourself is what do I, or the client, want as an end result. ... the damage to the photograph - the tears, rips, scratches, stains, etc. ... thus my original post inquiring about making the face better. ...
    (alt.graphics.photoshop)
  • Re: a few questions about broadcast
    ... I tried to have on the client in addition to the "broadcastclient" ... ntpd stability, precision, or accuracy. ... > servers on the subnet even though only 2 servers broadcast, ...
    (comp.protocols.time.ntp)
  • Re: negative estbdelay?
    ... autokey dance and as a result is unable to estimate the delay between ... the broadcast client and the broadcast server. ... client or server config file so it's hard to be sure. ...
    (comp.protocols.time.ntp)