OK, I should have read your previous post more carefully. You're saying that the host will simply reject a delta if it doesn't have the signer info, thus forcing the remote to send it and then re-transmit the delta. That will work. It also reduces the amount of state the host has to keep track of. That's something I hadn't considered.
On Sat, Nov 7, 2009 at 5:58 PM, Ben Kalman <[email protected]> wrote: > As I said before, the host of a wavelet should not have to deal with > certificate distribution itself, it should just accept and distribute > updates to wavelets. This is why the host will not do a getDeltaSignerInfo. > > > On Sun, Nov 8, 2009 at 12:54 PM, Tad Glines <[email protected]> wrote: >> >> Sending the same certificate chain with each delta is a massive waste >> of bandwidth. >> There is no reason to send the same exact chain each time. If the only >> way to get a cert chain was via getSignerInfo then server's would only >> need to ask once for each new signer info id encountered. >> Yes there is a little extra delay with that first delta containing a >> new signer info id, but it'll save on lots of bandwidth later. >> >> >> On Sat, Nov 7, 2009 at 5:38 PM, Ben Kalman <[email protected]> wrote: >> > Whenever a server send a signed delta (whether that be due to >> > broadcasting >> > an update as the host, or submitting a delta as the remote) the >> > receiving >> > server must be able to verify the delta, so must have the corresponding >> > certificate (signer info) for the signer id encoded into the signed >> > delta. >> > >> > Whether the server gets this through being posted the signer info >> > (postSignerInfo) or whether it has to request it (getDeltaSignerInfo) >> > depends on where the wavelet is hosted -- it is up to the remote server >> > to >> > ensure that all the certificates in place, i.e. the host server should >> > never >> > have to worry about distribution of certificates. So the remote must >> > getDeltaSignerInfo if it receives an update with a missing certificate, >> > and >> > postSignerInfo on every submit. >> > >> > So, two separate issues with this: previously (up until a9597f31ff) >> > there >> > was a rather bad shortcut taken to avoid the complications of >> > callbacks/queuing (tight time schedule :), where certificates were >> > posted to >> > remove servers from the host on updates. This has been fixed. >> > >> > The other issue is (as Tad noticed) a certificate is posted with every >> > submit. This is necessary based on an assumption that the host doesn't >> > have >> > our certificate, since we have no way of knowing this. It's also >> > somewhat >> > realistic given that FedOne servers don't persist certificates. >> > However, >> > once we formalise an error spec (soon) and FedOne/Google supports >> > propagation of error messages/codes (soon), the plan is for the host to >> > reject signed deltas with are missing signer info with a recognisable >> > error >> > code, so that the remote can then send the signer info only when >> > required. >> > >> > Hope that made sense :-) >> > -- Ben >> > >> > >> > On Sun, Nov 8, 2009 at 7:20 AM, Daniel Danopia <[email protected]> >> > wrote: >> >> >> >> This is funny because Sails hasn't gotten a single certificate in over >> >> a week from FedOnes, since FedOne requests them now xD >> >> >> >> On Nov 6, 8:28 pm, Tad Glines <[email protected]> wrote: >> >> > It looks like FedOne will post signer info to the fed host every time >> >> > it sends a delta. >> >> > This seems very inefficient. It seems to me that FedOne should only >> >> > send signer info as a result of a direct request. >> >> > >> >> > I thought I might have seen an issue or code review request related >> >> > to >> >> > this, but I couldn't find it. >> >> > >> >> > -Tad >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
