On Wed, Jul 14, 2010 at 14:19, mark.t.macdon...@googlemail.com
<mark.t.macdon...@googlemail.com> wrote:
> Let's assume I'm designing a distributed (client-server) application.
> The server owns a bunch of parameters. The client (GUI) is to be
> periodically updated when any of their values change.
> I could:
> i) send a small wire message containing one field each time it changes
> ii) periodically send a big wire message containing only the fields
> which have changed
> iii) periodically send a big wire message containing all current
> values
> Which approach is best and why?

This is a broad question and entirely depends on your application, the
size of the data to be transferred, the frequency of changes, the
'cheapness' of network, latency, the number of fields...
Any of your options you mention above can be the best for your application.
You need to be clear what you want to optimize for and then implement that.

> Should optional fields only be added/removed at design-time, or is it
> ok to vary their presence at runtime too?

You can send additional fields over the wire that are not specified in
the (think extensions:
But of course, your client/server need to be able to make sense out of it.

Best to start with is probably to write your proto buffer with a bunch
of optional fields and fill out the ones you're interested at the time
(so design time approach). Note, that only the optional fields that
you fill are actually transferred over the wire, so it is 'cheap' to
have many fields defined if you only send a few of them.

> How do I learn best practices for designing messages and exchange
> protocols?

Be clear about what you want to achieve and write down some parameter
you want to control (such as bandwidth). Then apply good judgement.
And over time, you collect best practices :)


You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to