Hi everybody,
how can I detect a dead server with *DTLS*?
I'm developing an application (IPFIX exporter and collector) that only
*sends* data using DTLS over UDP. Imagine the collector (DTLS server)
crashes and comes up again. The exporter (DTLS client) does not notice
the fact that the serve
> Please note that I can not solve this problem via the protocol that I
> use on top of DTLS - which is IPFIX - because IPFIX - by definition -
> only *sends* but does not receive data. I.e. I can not infer that the
> server crashed from the fact the he does not send any data because he
> does not
Hi Daniel,
why not use DTLS on top of SCTP? SCTP would check using its heartbeat
mechanism
whether the connection is still alive.
Best regards
Michael
On Jan 19, 2009, at 10:47 AM, Daniel Mentz wrote:
Hi everybody,
how can I detect a dead server with *DTLS*?
I'm developing an application
On Mon, Jan 19, 2009 at 10:47 AM, Daniel Mentz wrote:
> Please note that I can not solve this problem via the protocol that I use on
[...]
> the fact the he does not send any data because he does not send data anyway
> (except Handshake messages like ServerHello, ServerKeyExchange, etc.). I
> gues
Thank you all for your answers.
I think I will go for the hack that misuses re-negotiation as a kind of
heartbeat, keep alive or echo request. I tried to avoid this hack at
first because it is a computational burden. AFAIK re-negotiation means
restarting from scratch which means that expensive pu
Hi Daniel,
comments in-line.
Best regards
Michael
On Jan 19, 2009, at 10:54 PM, Daniel Mentz wrote:
Thank you all for your answers.
I think I will go for the hack that misuses re-negotiation as a kind
of
heartbeat, keep alive or echo request. I tried to avoid this hack at
first because it
> I think I will go for the hack that misuses re-negotiation as a kind of
> heartbeat, keep alive or echo request. I tried to avoid this hack at
> first because it is a computational burden. AFAIK re-negotiation means
> restarting from scratch which means that expensive public key operations
> hav
Hi Giang,
I think Robin tested it, so yes it works... But you need the bugfixes
he sent to the list...
Robin: Am I right?
Best regards
Michael
On Jan 20, 2009, at 5:59 PM, Giang Nguyen wrote:
I think I will go for the hack that misuses re-negotiation as a
kind of
heartbeat, keep alive or
> I think Robin tested it, so yes it works... But you need the bugfixes
> he sent to the list...
>
> Robin: Am I right?
actually i referred to session resumptions with abbreviated handshakes.
i think the "bugs/patches" comment was in the context of renegotiations with
full handshakes.
"> Btw, d
Hi Robin,
what would be needed to add support for renegotiations in DTLS?
Best regards
Michael
On Jan 20, 2009, at 7:01 PM, Robin Seggelmann wrote:
Hi Michael,
unfortunately, you're wrong. You need my patches to perform
renegotiations at all, since the current implementation is broken in
On Jan 20, 2009, at 9:58 PM, Robin Seggelmann wrote:
Hi Michael,
since there seems to be no function, option or whatever to trigger
session resumption for an established connection, I would have to
modify the API to add this functionality. This is kind of critical
because it would not only
Hi Michael,
unfortunately, you're wrong. You need my patches to perform
renegotiations at all, since the current implementation is broken in
this respect. Technically, the abbreviated handshake is supported, but
OpenSSL does not provide any API to initiate it without reconnecting.
The func
Hi Michael,
since there seems to be no function, option or whatever to trigger
session resumption for an established connection, I would have to
modify the API to add this functionality. This is kind of critical
because it would not only affect DTLS but also TLS which supports
session resu
13 matches
Mail list logo
