Re: [Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-05 Thread Paul Wouters
On Fri, 5 Mar 2021, Andrew Cagney wrote: The original idea was that connections were immutable -- all changes were in state objects. I think that explains: - /* my stuff */ - - /* Phase 2 ID payload info about my user */ - uint8_t st_myuserprotoid; /*

Re: [Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-05 Thread Andrew Cagney
On Tue, 2 Mar 2021 at 12:52, Paul Wouters wrote: > > On Tue, 2 Mar 2021, D. Hugh Redelmeier wrote: > > > | - instantiate non-template connections (this idea keeps coming up on IRC) > > > Then connections were derived from other ones, with more details > > filled in. This was instantiation. It

Re: [Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-02 Thread D. Hugh Redelmeier
| From: Andrew Cagney | (is "coding twine" original?) "Baling wire" is a term of art for jury-rigged fixes. "Haywire" is another word for baling wire, but with difference connotations.. All the balers we had used "binder twine". Baling wire seems like a bad idea. It seems easy to be leave

Re: [Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-02 Thread Andrew Cagney
> - .has_client implies that .client's subnet is valid > even though the actual connection's subnet/port was written into > .client the subnet part is assumed to be unchange > > - .protocol+.port (which presumably are never unchanged) are used when > trying to match connections > The .client's

Re: [Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-02 Thread Paul Wouters
On Tue, 2 Mar 2021, D. Hugh Redelmeier wrote: | - instantiate non-template connections (this idea keeps coming up on IRC) Then connections were derived from other ones, with more details filled in. This was instantiation. It could happen for a variety of reasons and with a variety of

Re: [Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-02 Thread D. Hugh Redelmeier
| From: Andrew Cagney | - instantiate non-template connections (this idea keeps coming up on IRC) This is off the top of my head. It might be wrong. And too philosophical. The original idea was that connections were immutable -- all changes were in state objects. It was convenient to add

[Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

2021-03-02 Thread Andrew Cagney
I just pushed this change into the opportunistic code: -* if we have protoport= set, narrow to it and zero out -* ephemeral port -* -* warning: we know ports in this_client/that_client are 0 so -* far -* -* XXX: ? +* Save the