CFTP (Classic Forum Transfer Protocol)
Christian Kruse
the last couple of days I had some time to think about the CFTP. While I
used an own protocol a few years ago, I now think it would be nice to
use an existing protocol. It has to be stateless and RESTful, because
I'd like to get away from the threading model that one worker servers
a complete client. I'd like the clients to be able to store a socket
with an existing connection in memory to avoid the connection overhead,
therefore a worker should return the client to the connection pool after
serving a request.
So, the protocol which comes to my mind immediately is HTTP. A typical
read request could so be:
GET /threadlist HTTP/1.1
Connection: keep-alive
Accept: *
HTTP/1.1 200 Ok
Date: Sat, 21 Aug 2010 20:04:49 GMT
Transfer-Encoding: chunked
Content-Type: text/plain; charset=utf-8
To transfer the thread data we could easily use JSON:
[
{
id: 't1',
postings: {
id: 'p1',
author: 'Jon Doe',
email: 'j...@example.org',
homepage: 'http://example.org/',
content: 'This is just an example',
children: [
{
id: 'p2',
author: 'Jon Doe',
email: 'j...@example.org',
homepage: 'http://example.org/',
content: 'This is just an example',
}
]
}
},
{
id: 't2',
postings: {
id: 'p3',
author: 'Jon Doe',
email: 'j...@example.org',
homepage: 'http://example.org/',
content: 'This is just an example',
children: []
}
}
]
We would have no proprietary protocols and would use only existing and
open standards. What do you think?
Greetings,
CK
Christian Seiler
> We would have no proprietary protocols and would use only existing and
> open standards. What do you think?
I completely agree. JSON/HTTP has somehow become a standard for certain
types of server applications (just look at e.g. CouchDB) and I like the
idea of making the whole thing stateless.
Viele Gr��e,
Christian
Alexander Nitsch
> It has to be stateless and RESTful, because I'd like to get away from
> the threading model that one worker servers a complete client. I'd like
> the clients to be able to store a socket with an existing connection in
> memory to avoid the connection overhead, therefore a worker should
> return the client to the connection pool after serving a request.
Ok, let's see if I understand this correctly. We have fo_server running as
the server, spawning several worker threads and waiting for requests from
the clients (fo_post, fo_view etc.). Currently, a request from the browser
calls one of the client programs, which in turn sets up a connection to
the server (i.e. one of its worker threads). This either uses sockets or
shared memory. Client and server exchange information over a stateful
protocol and then terminate the connection. The client processes the data,
delivers its output and exits.
Now, instead of using a stateful protocol for client-server communication
you would like to use a stateless protocol, which sounds fine to me. You
mentioned keep-alive connections, but is there really any need for them?
This would only make sense if client and server had more than one
request/response to exchange _per user-initiated session_, wouldn't it.
Does this ever happen? The client sends user authentication and actual
request in one go, the server will reply accordingly and the client will
exit after delivering this response to the user. What would a realistic
request, that utilizes keep-alive connections between client and server
look like?
--
Alex
Christian Seiler
> Now, instead of using a stateful protocol for client-server
> communication you would like to use a stateless protocol, which sounds
> fine to me. You mentioned keep-alive connections, but is there really
> any need for them? This would only make sense if client and server had
> more than one request/response to exchange _per user-initiated session_,
> wouldn't it.
You are forgetting that we want to use FastCGI as an option in the
future, so that a "client" process will live much, much longer than a
single request. It is very possible that it will handle requests from
multiple different users.
Of course, when using CGI the keep-alive stuff will not really be
beneficial (although it could be that a client process may need to send
two requests to the server) - but the protocol would support both use
cases.
Regards,
Christian
Christian Kruse
Hi Alex,
Since I'm travelling right now just a short answer: since we (first) aim FastCGI as the target plattform the client processes don't exit after serving a request. More when I arrive in Basel.
Am 22.08.2010 11:47 schrieb "Alexander Nitsch" <nit...@cs.tu-berlin.de>:
Hi.
> It has to be stateless and RESTful, because I'd like to get away from the threading model that o...
Alexander Nitsch
> You are forgetting that we want to use FastCGI as an option in the
> future, so that a "client" process will live much, much longer than a
> single request.
Ah, I see. Totally forgot about FastCGI ...
Regarding the HTTP/JSON approach: Sounds good. And since client and server
will be exchanging mostly text anyway, JSON won't introduce much overhead
I suppose.
--
Alex