Thank you for your reply! I understand your meaning that we should reuse existing module as much as possible.
You mentioned that a job that isolate HTTP handing from core is under developing and a experimental SPDY module exists. Could I access this developing project? And I'm willing to join it. I have a completely idea about implementing a SPDY module base on current architecture. Best regards, Wheats 在 2013-4-17，下午8:03，Sonny Karlsson <[email protected]> 写道： > 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
_______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
