6 Nov
2009
6 Nov
'09
9:52 a.m.
On Nov 02, 2009 at 19:34, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei Pelinescu-Onciul schrieb:
Yes and it is already implemented (tcp_send takes both a from and a to),
but it's not activated.
btw: can this be extended to take a string (e.g. domain) too - to differ
TLS connections which point to the same IP:port but are targeting
different domains (e.g. multi-domain TLS hosting using server_name
extension) ?
Theoretically yes. I'm not sure about the performance impact for no-TLS.
Maybe if we could get an integer id from the string (both less memory
and faster)...
Anyway let's have async TLS first and then will see :-)
Andrei
On Nov 02, 2009 at 08:19, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
>
>Andrei Pelinescu-Onciul schrieb:
...
I can add the force_send_socket() sets src. for tcp new
connection
feature quite easily, the question is whether or not to do it on sr_3.0.
IMO
choosing the src-IP dynamically is an important feature. But
probably others have to decide if it can make it into 3.0.
One difference from k would be that in k (and
older ser) a connection
from IP1->X is equivalent to IP2->x (only the destination is used, if
for example you do force_send_socket(IP2); forward...(X) and a connection
from IP1 -> X already exists, this connection will be used and no new
connection will be created) while in sr the connections will be
different (both the source and the destinations are used => in the above
example a new IP2 -> X connection will be opened even if IP1 -> X
already exists which IMHO is the correct thing to do).
So, it is not implemented
yet, but if you would implement it, then both
(source+dst) will be used as connection identifier?