[elvin-discuss] UDP mode

[Andrew Davison]

Thanks, that's what I thought. UDP is workable, though unreliable, as 
long as the client uses the same local port for sending throughout the 
session. It's a pity that NotifyEmit doesn't have a response and that 
NotifyDeliver doesn't have a sequence # per session.

Andrew

David Arnold wrote:
> -->"Andrew" == Andrew Davison <andrew at infradig.com> writes:
>
>   Andrew> Playing around in UDP mode and noticed that Sticker then does
>   Andrew> not bother with ConnRqst/DisconnRqst messages, just blindly
>   Andrew> starts adding subscriptions and doing notifies. Is this right?
>
> err, no.
>
> in terms of the abstract protocol:
>
> there is a UNotify packet, which is the only packet allowed to be used
> outside a logical connection established using ConnRqst/ConnRply.  it is
> intended for extremely light-weight producers, such as environmental
> sensors, etc.
>
> you cannot use UNotify within an existing logical connection, and you
> cannot use subscriptions, quenches, TestConn/ConfConn, QosRqst/QosRply,
> SecRqst/SecRply, etc, without a logical connection.
>
> when a router accepts an incoming physical connection, it waits for
> either a ConnRqst, UNotify or a timeout.  anything else should cause the
> physical connection to be dropped.
>
>
> channels can be established over any reliable, two-way transport.  by
> default, this is TCP.
>
> the Mantara/DSTC code implements a fairly bogus UDP protocol module.
> it's bogus because it doesn't deal with dropped packets (and maybe not
> with packets larger than 64K?), and to safely implement the abstract
> protocol, it should.
>
> we have occasionally talked about a "udp2" protocol which addressed
> these failings, but it's never seemed worthwhile.
>
>
> i haven't seen the behaviour you describe from Sticker before.  Sticker
> uses Mantara's Java-Elvin classes, so i'll take a look when i get a
> chance.
>
>
>
>
>
> d
>
>
>