Yes, the whole Push/Pull approach is complex and if it can be avoided, lucky you. As any programmer can attest to, it's always nice to discover the pittfalls of an approach to a problem BEFORE spending a couple of weeks persuing the solution, only to learn something which destroys that beautiful solution you were working on. I felt it my obligation to share some of my experiences if there was any chance of it saving you or someone else a lot of waisted time. Good luck!
Lee ----- Original message ----- From: "Murat OZDEMiR" <[EMAIL PROTECTED]> To: [email protected] Date: Wed, 28 Mar 2007 17:13:39 +0300 Subject: RE: SocketConnector Closes Session at 20 sec. Hi Lee, I see that you've struggled desperately with http protocols very much :) First of all thank you for patience to write that long email. That's great! God bless your hands ;) The HttpChannel with PUSH & PULL SocketSessions method seems usefull but a little bit complex. For now, i've solved my problem using HTTP/1.1 with Connection: Keep-Alive header. But that long text admonished me not to use http proxy between my http client application and the server. I'll cary on untill one day i have to use proxy server between client and http server. Have a good day ;) ---------- Murat -----Original Message----- From: Lee Carlson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 4:20 PM To: [email protected] Subject: RE: SocketConnector Closes Session at 20 sec. Murat, I've been using a remoting framework which I initially created based on mina, with the purpose of using http to create a persistent bidirectional connection when NAT/Firewall prevents persistent TCP connections. During this endevour, I encountered the same problems as you with the HTTP connections being closed, but often you don't see this behavior until you go through a proxy server which almost always will close the connection after the response is received. Almost all web servers today support HTTP 1.1 and keep-alive, but although proxy servers ussually support 1.1, they still add the "connection: close" header to the response because they can't afford to keep the connection open to the client, because to do so means they also have to keep it open to the server and this does not scale well (not using blocking sockets anyway). There may be a proxy server which doesn't do this, but I haven't seen one. Bottom line is that you have to live with the connection closing after every response in order to support common http usage today (proxy servers). In my case the solution was to create an additional layer of abstraction on top of the SocketSession which I called my HttpChannel. The HttpChannel actually contains two SocketSessions which work together to create one "ChannelSession" which appears to never be disconnected, and is where I locate the filters such as SSL so that they don't have to be reestablished after every SocketSession disconnection. The way it works from the client side, is that you have one SocketSession used to PUSH data to the server, then when the server receives the data it knows it's a PUSH request and must return a response immediately, and will bundle a few queued messages in the http response destined for the client as well (if any). The other SocketSession is the PULL session, which is how the server is able to send data to the client at anytime. The client sends an http request (even if empty) to the server, and the server see's that it is a PULL request so it does not send a response, until it has data to send to the client, or the connection is closed due to timeout. Because the response is not sent, the client and any proxy servers will hold the sockets open. If the connection is closed it is immediately reestablished. Using this combination of PUSH and PULL SocketSessions managed inside the HttpChannel, a single virtual bidirectional "channel" is maintained between a client and server, even with proxy servers inbetween closing connections all the time. Works great. So, moral of the story is try to make your solution work supporting http 1.0. Even if you use chunked encoding, you have to watch out for Proxy servers which are also doing Anti-Virus checks, because they will often buffer the entire chuncked encoding so that they can perform the virus scan on the complete message, which negates the purpose of chunked encoding. Ok enough already, someone pry my hands off this keyboard...! Lee Carlson ----- Original message ----- From: "Murat OZDEMiR" <[EMAIL PROTECTED]> To: [email protected] Date: Wed, 28 Mar 2007 11:04:30 +0300 Subject: RE: SocketConnector Closes Session at 20 sec. Thank you very much Niklas, I guess you're right. Using HTTP/1.0 i'm receiving expected response but connection is closed. **************************************************************************** **************************************************************************** **** REQUEST GET /DEKA-SMSCServlet?cmd=REGISTER&pPwd=xxxxx&pUser=YYYYYYY& HTTP/1.0 Connection : Keep-Alive Host : elcosis.com:8585 Accept-Language : tr Content-Type : application/x-www-form-urlencoded - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - RESPONSE HTTP/1.1 200 OK Content-Length: 277 Date: Wed, 28 Mar 2007 07:59:06 GMT Server: Apache-Coyote/1.1 Connection: close cmd=REGISTER&pUser=&pPwd=&pSessionId=200703281059069550&pRetCode=200&pServic e_Code=5141&pSubService_Code=&pMsisdn=&pDstMsisdn=&pContent=&pContentId=&pMu ltiplier=&pSend_Date=&pDelete_Date=&pXser=&pNreq=&pMsgId=&pStatus=&pSender=& pSrvSNCode=&pId=&pSourceMsisdn=&pErrCode=0&pRpid= I've tried HTTP/1.1 one but i've received HTTP/1.1 400 Bad Request. Do you know why? **************************************************************************** **************************************************************************** **** REQUEST GET /DEKA-SMSCServlet?cmd=REGISTER&pPwd=xxxxx&pUser=YYYYYYY& HTTP/1.1 Connection : Keep-Alive Host : elcosis.com:8585 Accept-Language : tr Content-Type : application/x-www-form-urlencoded - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - RESPONSE HTTP/1.1 400 Bad Request Transfer-Encoding: chunked Date: Wed, 28 Mar 2007 07:50:26 GMT Server: Apache-Coyote/1.1 Connection: close 0 **************************************************************************** **************************************************************************** **** ---------- Murat OZDEMIR -----Original Message----- From: Niklas Therning [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 10:44 AM To: [email protected] Subject: Re: SocketConnector Closes Session at 20 sec. Well AFAIK that's the normal behaviour in HTTP 1.0, the client connects, sends an HTTP request, gets a response and the server closes the connection. You need to be using HTTP 1.1 and specify in the HTTP request that the connection should be kept alive I think (using the header Connection: keep-alive). /Niklas Murat OZDEMiR wrote: > > I've now tested using other simple TCP client utility, and faced that > one of them is closing connection after around 20 seconds but the > other is not. The problem is when i send a http request, the > connection/session is closed as soon as response is received. > I should find out why. > Any comments? > > ---------- > Murat OZDEMIR > > -----Original Message----- > From: Murat OZDEMiR [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 28, 2007 10:33 AM > To: '[email protected]' > Subject: RE: SocketConnector Closes Session at 20 sec. > > First is "Apache-Coyote/1.1" which belongs to us and second is > "Apache/1.3.37 (Unix)" which belongs o GSM operator smsc http server. > > ---------- > Murat OZDEMIR > > -----Original Message----- > From: Niklas Therning [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 28, 2007 10:09 AM > To: [email protected] > Subject: Re: SocketConnector Closes Session at 20 sec. > > What server are you connecting to? Could it be that the server closes > idle connections after 20 seconds of idleness? > > /Niklas > > Murat OZDEMiR wrote: > >> Latest news about " SocketConnector Closes Session at 20 sec." >> >> I have a poller method which is executed at every 20 seconds by a >> timer schedule. So i see that the socket is closed after 20 seconds. >> But i guess that session is closed whenever a http response received >> from >> > web server. > >> You can find an image attached. A thread named >> "SocketConnectorIoProcessor-0.0" is somehow closed. I don't know why. >> Any comments? >> >> ---------- >> Murat OZDEMIR >> >> -----Original Message----- >> From: Trustin Lee [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, March 28, 2007 5:40 AM >> To: [email protected] >> Subject: Re: SocketConnector Closes Session at 20 sec. >> >> Hi Murat, >> >> On 3/27/07, Murat Ozdemir <[EMAIL PROTECTED]> wrote: >> >> >>> Hi all, >>> SocketConnector closes Session at 20 sec. when idle. But i have set >>> the worker timeout to 100 sec. >>> >>> Despite >>> // worker timeout to 100 second to make the I/O thread quit soon >>> connector.setWorkerTimeout( 100 ); >>> >>> >> I/O processor will never quit if there's any connected session. The >> worker timeout is applied only when there's no connected. Therefore, >> you don't need to adjust this property at all. >> >> >> >>> and >>> // HTTP_CONNECT_TIMEOUT = 10 sec. >>> cfg.setConnectTimeout( >>> SmsCenterConstants.HTTP_CONNECT_TIMEOUT ); >>> >>> >> The connect timeout is applied only for a connection attempt. If the >> session is already connected and created, this property doesn't >> affect the session at all. >> >> I suspect that you set idle time to 20 seconds, or the client is >> configured to close the connection when it's idle for 20 seconds. >> The code will look like this for example: >> >> session.setIdleTime(IdleStatus.BOTH_IDLE, 20); >> >> HTH, >> Trustin >> -- >> what we call human nature is actually human habit >> -- >> http://gleamynode.net/ >> -- >> PGP Key ID: 0x0255ECA6 >> >> > > > > -- Niklas Therning www.spamdrain.net
