Re: [Regops] draft-wullink-restful-epp-00.txt
Francisco Obispo <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On Apr 23, 2012, at 10:57 AM, Gould, James wrote: > Francisco, > > So your proposal is to make it stateful based on the HTTP session? This Yes, you can keep HTTP-session information in a shared way across multiple servers (memcached, SQL-db, etc). so you can have any front-end server vailidate it. Clients can keep the connection (or session) alive by issuing commands periodically. > would mitigate the authentication per command issue; although it is > switching the discussion from stateless back to stateful. There is still > the connection establishment overhead (2-way SSL) that will decrease the > performance. On the client side, you could have pre-cached connections with multiple servers. > Do you have a proposal to mitigate that? Is there an > perceived problem in scaling registry services that needs to be solved and > if so can you provide any details? I believe that the registries have > shown that EPP can scale without the need to add HTTP to the stack. We > defined and used an EPP HTTP transport for over 6 years, which did allow > for scaling the server-side using standard web scaling techniques. HTTP > keep-alive was used to maintain the EPP session with the server. EPP TCP > did perform better since it didn't include the HTTP overhead in the stack. > The EPP HTTP transport was lightly used since the preference was to use > EPP TCP, but this is an option to consider. I guess something like this could be implemented with EPP (over TCP), by building an extension to deal with the session information: 1) EPP <login> authenticates and generates a cookie (stored in a shared system) that gets sent in the <extension> section 2) Subsequent requests are validated with that cookie 3) EPP <logout> destroys the cookie on the server side. That way, clients could contact any EPP server in you pool, and get service by showing a valid session cookie. Francisco > > > -- > > JG > > > > James Gould > Principal Software Engineer > [email protected] > > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com > > > > > > > > On 4/23/12 1:05 PM, "Francisco Obispo" <[email protected]> wrote: > >> >> You could initiate a session with a RESTful server, just like most >> websites work: >> >> - You will use a RESTful URL to create a session: /session/user_id [POST] >> >> - The server would return a cookie, which you will return with every >> RESTful request. >> >> - When you're done processing requests you can: /session/user_id [DELETE] >> >> The advantage of this model, is that you can use the existing knowledge >> on how to scale web-services and apply them to Registry-Registrar >> interactions. >> >> Francisco >> >> >> >> >> On Apr 23, 2012, at 9:26 AM, Gould, James wrote: >> >>> Passing the user credentials to authenticate the user on a per >>> command basis will also add a lot of extra overhead. Can someone >>> describe >>> how these elements will be mitigated in a stateless model? Overall, I >>> don¹t see how moving from stateful to stateless will benefit either the >>> client or the server from a performance or load perspective. >> >> Francisco Obispo >> email: [email protected] >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID = B38DB1BE >> > Francisco Obispo email: [email protected] Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg