Comments (5)
@suvl, after some discussion with @ctorrao we came to the conclusion that a better approach may be to have a KnownAddresses
list which would be sent to the Registry in the Ping stage. This list would be populated with the port and possibly the IP from the requested URL, effectively using the information that the client used to make the request to the application.
Because, even if we went for the IIS approach, there may be more WebSites hosting the application, and in OWIN/Asp.Net Core self-hosted scenarios it would be impossible to know the port, making it inconsistent.
This would, of course, be more complex, and probably move this to the 1.1.0 milestone.
What's your toughts?
from name-sdk.
@Symbianx you are proposing to maintain an ISet<>
of known addresses, built from capturing the HttpContext.Request
on every request and check hostnames, ports, whatnot for novel addresses?
I know it is perfect from the NAME Registry requirements' point of view. I'm concerned about the possible impact on the pipeline we cannot foresee. Shall we first measure the impact of such an interception? Is there any way it can be offloaded or maybe a way to O(1) detect what does not require processing?
Plus, from that point on, the Registry would have to support multi-addresses, maybe?
/cc @ctorrao
from name-sdk.
The performance impact is a great point, regarding the collection used we could use an HashSet<T>
implementation which provides O(1) for both manipulation AND lookup.
To improve performance further we could store the strings containing the full left part of the URL, without any transformations.
Also, we can consider only taking into the account the URLs of the request against the /manifest
endpoint, which would not create an impact on the existing app flows, but could reduce the number of 'known addresses'.
Edit:
Yes, we could improve the Central Registration protocol to support the 'Known Addresses' flow. Keeping the existant 'Port' field for the NAME self-hosted solution that knows the specific port on which it is listening, or we could deprecate the Port field.
from name-sdk.
I am not in favor of solely consider the /manifest
requests. In a real-world scenario with potentially hundreds of services in a massive microservice thingie, one would use the Registry to find out the /manifest
url to the service, not the other way around. Is this a classic chicken and the egg thing?
We must run some numbers to assess real impact from this. There's already a fragment of impact from adding the X-Name header, maybe we could use exactly that pipeline execution step? (afraid to break SOLID here)
About the protocol, I think it should move to version 2 with support for Known Addresses
and deprecation of Port
.
from name-sdk.
I'm not too fond of considering only the /manifest
request as well, so let's keep that option out for now.
Yes you can use the same extension point, and I agree that we need to assess the performance impact it will have.
I agree with the protocol.
from name-sdk.
Related Issues (19)
- Tab character before comments breaks the dependencies file parser
- Depency maximum version should support wildcards such as 3.* and 3.0.*
- CI builds should detect the build warnings HOT 1
- The manifest should have a relevant error message when NAME is not installed on the target dependency
- Add a connection string locator for environment variables HOT 1
- Exploring dependencies is making too many requests
- Support for getting Elasticsearch info HOT 2
- Provide status on the errors of the service's HOT 1
- Support Redis version resolving HOT 1
- Expose an endpoint that supports the mermaid syntax (flowchart)
- warning message should help resolve the issue HOT 1
- Add support for IConfigurationProvider in NAME.AspNetCore HOT 1
- Support Kafka version resolving in infrastructure dependencies
- The dependencies.json file should allow an override check condition (for non NAME services) HOT 1
- Error "Donβt know elementType=17" with MongoDB version checking HOT 2
- Startup healthcheck should be async when ThrowOnDependenciesFail is false
- NAME should retry to fetch the manifest when the serialization fails
- Manifest UI accesses the HTTP endpoint when behind a SSL Termination proxy
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from name-sdk.