Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link all single client connections with an appropriate peer #235

Closed
keshonok opened this issue Sep 7, 2015 · 2 comments
Closed

Link all single client connections with an appropriate peer #235

keshonok opened this issue Sep 7, 2015 · 2 comments
Assignees
Milestone

Comments

@keshonok
Copy link
Contributor

keshonok commented Sep 7, 2015

Currently a peer is created for each client connection even though the connections may be coming from the same client. As a result there are multiple TfwClient{} instances for the same peer.

One TfwClient{} instance should be created for each client. An incoming connection should be matched with a specific peer (TfwClient{}), and it should be linked with that peer. In the end, there should be a large number of client connections linked to a smaller number of peers.

Peers are identified by a specific set of attributes, such as an IP address, etc. So there's a task of maintaining a store of peers that provides for fast insert/delete/search, perhaps a hash. Frang deals with a very similar, if not the same task. There needs to be a single store of peers that Frang, the client code, and the rest of code can use.

Frang needs to be reworked to use a single store of peers.

@krizhanovsky krizhanovsky added this to the 0.5.0 Web Server milestone Sep 7, 2015
@krizhanovsky
Copy link
Contributor

The issues was left as TODO. Somewhat linked with issues #100, #116 and #145: client connections management.

@krizhanovsky
Copy link
Contributor

krizhanovsky commented Aug 4, 2016

There are also several problems linked with the issue:

  1. Security. Currently we don't check Sticky cookie value at all, i.e. malicious user can send us arbitrary cookie value and we pass the request to backend server. To fix the issue we must compare received cookie value with the stored in TfwClient. This must be done in tfw_http_sticky_found().
  2. Sessions. (1) requires to store cookie value. However, since the same TfwClient now can maintain many TfwConnection which easily can have different HTTP sessions (send different sticky cookie values), we have to introduce new entity - TfwSession which exactly describes HTTP session. (Meantime, one there can be many HTTP sessions within the same TCP connection). TfwSession must handle at least HTTP session timestamp and sticky cookie value.

Sessions must be implemented in this task since now TfwClinet servicing many connections can not have cookie member which is actually per-session member, so TfwSession abstraction must be introduced to track HTTP sessions identified by sticky cookies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants