> On July 1, 2015, 6:47 p.m., Ted Ross wrote: > > I hate to say this, but shouldn't you just handle the defaults for > > max-frame-size and idle-time-out while you're in there? You're doing the > > timing belt, may as well change out the water pump while you're in there.
that may not be necessary - remote_max_frame and remote_idle are initialized to zero locally, and they are only considered provided by the remote if they are non-zero after the open arrives. - Kenneth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36098/#review90100 ----------------------------------------------------------- On July 1, 2015, 6:02 p.m., michael goulish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36098/ > ----------------------------------------------------------- > > (Updated July 1, 2015, 6:02 p.m.) > > > Review request for qpid, Gordon Sim and Kenneth Giusti. > > > Repository: qpid-proton-git > > > Description > ------- > > PROTON-925 > Use a "this-variable-was-actually-scanned" flag to see if the value returned > by pn_data_scan() for remote_channel_max is real. If it's not real don't use > it. > > > Diffs > ----- > > proton-c/src/transport/transport.c 2271f27 > > Diff: https://reviews.apache.org/r/36098/diff/ > > > Testing > ------- > > ctest -VV > > and also -- the way gsim found this -- use a sender based on this new code > against a receiver based on 0.9 or older code. WIthout this fix, the sender > will hallucinate a "0" from the receiver because ... pn_data_scan() > overwrites addresses for which it received no value. > > > Thanks, > > michael goulish > >
