On Wed, Apr 17, 2013 at 01:00:58PM +0800, Haomai Wang wrote: > I understand. > > Could you provide with detailed demands about the limit to destroy current > architecture? > Such as don't add new field to critical structure or don't modify Http module.
As edsiper suggested it would be best if a SPDY implementation was stand-alone to begin with. However, you should probably give thought to how an HTTP implementation can use the changes you introduce. For example, the current header handling can probably not be reused, but a rewritten mechanism should be able to work with both HTTP and SPDY. Having two separate implementations of every detail different in HTTP and SPDY is not recommended. > > I need some hard limitation and soft limitation to observe with developing > SPDY module. > Because SPDY module is a large change to Monkey current architecture(the > modification > on current architecture is inevitably) and I'm a newer to Monkey anddon't > know the core > developer's *blueprint* about Monkey. I think I should know it and apply to > develop. There is work underway to isolate HTTP handling from the core in such a way that it will be easy to add a SPDY or HTTP 2.0 implementation. I have a branch that will allow a SPDY module to use the event handling and transport (SSL) of the monkey core, without the need to change anything else. What have not been done yet are changes to the plugin interface needed to handle either SPDY or HTTP requests. The branch is very experimental and I don't think it accessible on git.monkey-project.com yet. A SPDY implementation would receive notification of file descriptor events and act on them. It would need to parse requests, keep track of session and request data and of course answer with something. > > Thank you! > > Best regards, > Wheats > > > > 在 2013-4-17，上午12:06，Eduardo Silva <[email protected]> 写道： > > > i have talked with other core developer last night about spdy stuff, we > > will take care of the split of the http protocol and the layer to implement > > SPDY, so your proposal should focus in understand the current monkey > > architecture, how SDPY works , create a standalone server for demonstrative > > purposes and then the merge of that into Monkey. > > > > Btw, is good to mention that you have to assign the Copyright to Monkey > > Project of all your work. We will keep the code public as GPL. > > > > > > On Mon, Apr 15, 2013 at 9:22 AM, Haomai Wang <[email protected]> wrote: > > I omit a detail that adding a new field called "request_id" to > > session_request, and > > client_session manages all session_requests whch from the same file > > description. > > > > Best regards, > > Wheats > > > > > > > > 在 2013-4-15，下午11:16，Haomai Wang <[email protected]> 写道： > > > >>> It happen that for Monkey a client_session is identified by the file > >>> descriptor number and always a specific connection can be looked up based > >>> on that "primary key". In SPDY you have multiple streams in the same > >>> channel so the thing is "how to identify each specific request/stream". > >>> Keep in mind that Monkey is an async server so socket events can take > >>> place in different parts so you must be able to identify and get the > >>> specific data for that event. > >> Of course I know what is async server and what it means. > >> > >> Below I want to explain my understand of SPDY correspond to Monkey > >> structure: > >> session: One TCP connection one session, correspond to client_session > >> stream: one session multi stream concurrently, correspond to > >> session_request > >> > >> When new connection accepted, new session created. > >> When new packet received, mk_conn_read() read from `socket` and started to > >> parse it, > >> get stream id from SPDY packet and search the corresponding > >> session_request. If not, > >> create new session_request and handle it, otherwise get session_request > >> and handle it. > >> > >> If SPDY packet is incomplete because one stream packet from break into two > >> TCP > >> packet(Network issue) and we can save last incomplete session_request in > >> client_session. > >> If new TCP packet received, we check whether incomplete session_request is > >> existed. > >> Keep in mind that TCP connection guarantees packet ordering. > >> > >> Is this exists problem about my thought of implementation? I like detailed > >> example to refute > >> it. > >> > >> Your reply is welcomed ASAP. > >> > >> Best regards, > >> Wheats > >> > >> > >> > >> 在 2013-4-15，下午10:27，Eduardo Silva <[email protected]> 写道： > >> > >>> > >>> > >>> > >>> On Mon, Apr 15, 2013 at 7:08 AM, Haomai Wang <[email protected]> wrote: > >>> I don't understand your statement "the current core uses a client file > >>> descriptor as primary key to identify a request". > >>> A TCP connection is shared by multi "requests" already exists in Http 1.1 > >>> and SPDY only replace "request" by "stream". > >>> And SPDY is like pipelining HTTP requests which Monkey already supports. > >>> > >>> > >>> > >>> It happen that for Monkey a client_session is identified by the file > >>> descriptor number and always a specific connection can be looked up based > >>> on that "primary key". In SPDY you have multiple streams in the same > >>> channel so the thing is "how to identify each specific request/stream". > >>> Keep in mind that Monkey is an async server so socket events can take > >>> place in different parts so you must be able to identify and get the > >>> specific data for that event. > >>> > >>> > >>> In the past few days, I reviewed SPDY Protocol - Draft 3 detailed and > >>> find the most difficult thing is [1]how to integrate > >>> SPDY to existing HTTP module. > >>> > >>> There exists two ways: > >>> 1. Insert SPDY module as a optional module into the request processing > >>> chain. If so, SPDY module is only a gateway > >>> to change SPDY request into HTTP request format. We can reduce effects > >>> on other features and may be destroy > >>> Http module. > >>> > >>> Request -> Is SPDY request -> yes -> SPDY module(process Control Frame) > >>> -> Http module -> Services > >>> > >>> > >>> | > >>> response <------ > >>> SPDY module <---- Http module <---- | > >>> > >>> 2. Build a completely SPDY supporting and ignore existing HTTP > >>> implementation. > >>> > >>> > >>> > >>> that part requires to discuss more in detail. > >>> > >>> > >>> SPDY supports more features than HTTP such as server push, using common > >>> headers, CREDENTIAL and SETTINGS. > >>> [2]Is need to modify plugin API to support? > >>> > >>> Best regards, > >>> Wheats > >>> > >>> > >>> regards, > >>> > >>> > >>> > >>> > >>> 在 2013-4-12，上午11:55，Eduardo Silva <[email protected]> 写道： > >>> > >>>> indeed there are many changes to do, the current core uses a client file > >>>> descriptor as primary key to identify a request, in SPDY many requests > >>>> can exists under the same file descriptor, so that means a deep review > >>>> of the stack and start thinking how to adapt the current design to be > >>>> more protocol-agnostic without affect all features. > >>>> > >>>> try to reach us on irc.freenode.net #monkey > >>>> > >>>> regards, > >>>> > >>>> > >>>> -- > >>>> Eduardo Silva > >>>> http://edsiper.linuxchile.cl > >>>> http://www.monkey-project.com > >>> > >>> > >>> > >>> > >>> -- > >>> Eduardo Silva > >>> http://edsiper.linuxchile.cl > >>> http://www.monkey-project.com > >> > > > > > > > > > > -- > > Eduardo Silva > > http://edsiper.linuxchile.cl > > http://www.monkey-project.com > > _______________________________________________ > Monkey mailing list > [email protected] > http://lists.monkey-project.com/listinfo/monkey -- Sonny Karlsson _______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
