From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [SMS D-Bus 02/19] sms: introduce message ID API
Date: Thu, 05 Aug 2010 13:02:25 -0500 [thread overview]
Message-ID: <4C5AFCB1.1000901@gmail.com> (raw)
In-Reply-To: <1281028719.19261.82.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]
Hi Inaky,
>> The current message id is 32 bits. Why are we stopping at 16? We could
>> go all the way to 64 if needed...
>
> Well, at the end what gets sent to the network is 16 bits right?
So I think we're all confused here. This ID is not being sent to the
network. It is only used for uniquely identifying the message over
D-Bus and to message history. This number can be as small or as big as
we want.
>
>> Also, we need to take time and some random value into account. Perhaps
>> including time() output and a simple static counter into the hashing
>> function would make it unique for those 'same sender, same contents
>> messages'
>
> So then we really don't care about being able to regenerate the hash ID
> from the contents?
>
> The design discussions we held about this involved being able to, with
> the content of the message and destination number, generating a hash
> that could be uniquely reproduced by rehashing it again. You had a
> reason for it and I can't remember which one it was -- I should have
> written it down. But that brought the problem of 'somebody sending the
> same message to the same number' which yields the same ID.
>
> However, if to fix that we are adding randomness in the form of time(),
> why bother with the contents? let's just do a random ID from the ground
> up and save us the pain of hashing.
>
I don't remember this discussion any more. There might be a case where
an old message is re-delivered because oFono crashed after delivery but
before deletion.
At least to me it seems that generating a random int is really not
guaranteed to be unique over reboots. Hashing seems way better.
However, I'm not a math/crypto geek, so feel free to prove me wrong.
Regards,
-Denis
next prev parent reply other threads:[~2010-08-05 18:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 23:50 [SMS D-Bus 00/19] pull request Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 01/19] write_file: make transaction-safe Inaky Perez-Gonzalez
2010-08-05 17:03 ` Denis Kenzior
2010-08-03 23:50 ` [SMS D-Bus 02/19] sms: introduce message ID API Inaky Perez-Gonzalez
2010-08-05 17:10 ` Denis Kenzior
2010-08-05 17:18 ` Inaky Perez-Gonzalez
2010-08-05 18:02 ` Denis Kenzior [this message]
2010-08-05 18:07 ` Inaky Perez-Gonzalez
2010-08-05 18:21 ` Denis Kenzior
2010-08-05 18:37 ` Inaky Perez-Gonzalez
2010-08-05 23:34 ` Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 03/19] sms: implement SHA256-based message IDs [incomplete] Inaky Perez-Gonzalez
2010-08-05 17:20 ` Denis Kenzior
2010-08-05 18:17 ` Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 04/19] sms: document the org.ofono.SmsMessage interface Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 05/19] sms: document handle_sms_status_report() Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 06/19] struct tx_queue_entry: add a destructor Inaky Perez-Gonzalez
2010-08-05 17:04 ` Denis Kenzior
2010-08-03 23:50 ` [SMS D-Bus 07/19] sms: introduce bare state machine and transitions Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 08/19] sms: introduce the Wait-for-Status-Report state Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 09/19] sms: introduce a state change callback for messages Inaky Perez-Gonzalez
2010-08-03 23:50 ` [SMS D-Bus 10/19] sms: export outgoing messages over D-Bus Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 11/19] sms: send PropertyChanged signals on state change Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 12/19] sms: introduce sms_msg_cancel and its D-Bus wrapper Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 13/19] sms: Implement D-Bus SMS-MSG::GetProperties Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 14/19] sms: document SMS Message's D-Bus 'To' property Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 15/19] sms: test code for message's D-Bus GetProperties Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 16/19] automake: fix generation of symlinks for headers Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 17/19] sms: document variable usage in sms_msg_send() Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 18/19] sms: add test case for message cancel Inaky Perez-Gonzalez
2010-08-03 23:51 ` [SMS D-Bus 19/19] sms: add test case for state change signals Inaky Perez-Gonzalez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5AFCB1.1000901@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox