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.
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. 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
