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 -~----------~----~----~----~------~----~------~--~---
