Возможен ли FullDuplex для QHttp ?

[kuzulis]

Доброго всем здравия!

Собственно вопрос: возможно ли как-то "смастерить" FullDuplex для Http протокола , в частности для QHttp ?

очень нужно, чтобы "сервер" сам мог в любое время слать "клиенту" запросы!
т.е работа такая к примеру:
1. клиент подключается к серверу и шлет ему запрос
2. сервер ему отвечает
3. СОЕДИНЕНИЕ НЕ РВЕТСЯ!!!!
4. сервер в какой то момент времени шлет клиенту запрос
5. клиент отвечает
6. СОЕДИНЕНИЕ НЕ РВЕТСЯ!

т.е нужно чтобы канал всегда оставался открытым!

[Admin]

Помоему это противоречит принципу http протокола: запрос - ответ.
Реализовать можно - только клиента и сервер будете писать вы.

[kuzulis]

т.е сам клиент должен выступать в роли сервера?

[Admin]

ага
обычно такое делаю на xml
туда - сюда его гоняют)

[kuzulis]

Так значит нужно иметь (создавать) дополнительный порт для обратки?

т.е в одну сторону допустим порт 8080, в другую 8081... не хотелось бы добавлять лишнюю сущьность ...

[Mixolap]

ну если СОЕДИНЕНИЕ НЕ РВЕТСЯ, то одного порта достаточно должно быть, если конечно сам сервер не будет инициализировать подключения к клиенту (то есть без обмена ролями).

[kuzulis]

Я чего спросил, потому что непонятно как ведет себя QHttp после вызова:

Код:

int QHttp::request ( const QHttpRequestHeader & header, QIODevice * data = 0, QIODevice * to = 0 )

и получения ответа:

Код:

void QHttp::responseHeaderReceived ( const QHttpResponseHeader & resp )  [signal]

т.е непонятно:
1. при вызове request (в случае когда клиент уже подключен к серверу) - запрос пройдет?
2. происходит ли автоматически disconnect от сервера, когда данные от сервера приняты?

вот эти два момента в работе класса QHttp меня оч интересуют!

[sendevent]

если я правильно понимаю, одно из отличий хттп 1.1 от 1.0 - возможность установки "длительного" соединения, т.е. коннект устанавливается 1 раз, а не для каждого запроса. при этом время жизни соединения задается полем Keep-Alive, но потрогать не доводилось.

1. не совсем понятно - а чего ему не пройти? или речь идет не о клиентском (QHttp::)request'е?
2. при исопльзовании 1.0 (тот же мыло.ру) stateChanged( 0 ) приходит примерно через минуту после приема последних данных - возможно, это связано с сокетными таймаутами локальной ОС, но подозреваю - конфигурацией сервера.

[kuzulis]

1. не совсем понятно - а чего ему не пройти? или речь идет не о клиентском (QHttp::)request'е?

я может неправильно выразился.. имеется ввиду, посылается ли "connect" при запросе, т.е если гипотетически имеем в данный момент CONNECT к серверу, то  проверяется ли уже существующий CONNECT при реквесте? или как-то вот так то непонятно как??

2. при исопльзовании 1.0 (тот же мыло.ру) stateChanged( 0 ) приходит примерно через минуту после приема последних данных - возможно, это связано с сокетными таймаутами локальной ОС, но подозреваю - конфигурацией сервера.

так непонятно, а какую версию протокола использует QHttp ?

--

мне нужно будет реализовать используя библиотеку qxml-rpc (а как известно этот протокол через HTTP реализован) полнодуплексный обмен данными между клиентом и сервером, при этом подразумевается, что соединение должно поддерживаться постоянно!

т.е чтобы не только клиент-серверу мог слать запросы, но и сервер клиенту мог послать сам (спонтанно, при условии что клиент еще подключен) некие запросы!!!!
 

[sendevent]

1: если QHttp::state == QHttp::Unconnected то запрос не будет отправлен, и вроде не автоконнектится, надо QHttp::setHost делать. когда же коннект установлен - как тролли проверяют и проверяют ли - не задавался подобным вопросом
2: QHttp понимает обе, указание исопльзуемой версии - это уже из нотации самого хттп, задается в QHttpRequestHeader:

QHttpRequestHeader::QHttpRequestHeader ( const QString & method, const QString & path, int majorVer = 1, int minorVer = 1 )
Constructs a HTTP request header for the method method, the request-URI path and the protocol-version majorVer and minorVer. The path argument must be properly encoded for an HTTP request.

как видно, дефолтом используется хттп 1.1.