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.
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.
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
在 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
_______________________________________________
Monkey mailing list
[email protected]
http://lists.monkey-project.com/listinfo/monkey
