RE: Problem with blocking connect().

oh. you're talking about the WAP gateway part. sorry - I'm not using that functionality and so didn't think about it. in that case, then yes : we need to make sure that the HTTP handling thread does not get blocked by a single problematic server. that is a major problem, because I don't see how the current state machine can handle connect() multiplicity.

--
Oded Arbel
m-Wise mobile solutions
[email protected]

+972-9-9581711 (116)
+972-67-340014

::..
PLAN, v.t.
      To bother about the best method of accomplishing an accidental result.
	-- the Devil's Dictionary / Ambrose Bierce



> -----Original Message-----
> From: Vjacheslav Chekushin [mailto:[email protected]]
> Sent: Monday, October 21, 2002 3:30 PM
> To: Oded Arbel
> Cc: devel
> Subject: Re: Problem with blocking connect().
> 
> 
> Hi, Oded.
> Either I not correctly undestand kannel source or we talk 
> about different
> things.
> So I explain my point of view with little example.
> Suppose we have 5 clients with phones and they work simultaneously.
> They try to fetch some resources at once.
> The first one try to fetch http://foo.bar.com/index.html.
> It is unknown host for me and I can't be sure that it is not
> 'terribly malfunctioned server'.
> All 5 requests http_start_request puts in one queue and
> write_request_thread start to deal with this one by one.
> send_request use conn_open_tcp to foo.bar.com.
> At that point gateway blocks other 4 request untill connect 
> to foo.bar.com will
> return. In real life it meens that these 4 client (with 
> normal requests) will 
> receive 'gateway not responding' after timeout.
> Am I wrong with my scenario?
> 
> Oded Arbel wrote:
> 
> >>-----Original Message-----
> >>From: Vjacheslav Chekushin [mailto:[email protected]]
> >>
> > 
> >>Hi, Oded.
> >>As I undestand from kannel architecure, we have 1 thread that 
> >>write requests 
> >>from client to network. 
> >>
> > 
> > For HTTP alone, not every connection. 
> > 
> > 
> >>So if one connect will blocks for 1 
> >>minute, then thread
> >>stops to serve other requests for this time and other 
> clients wait for
> >>this time too.
> >>
> > 
> > I don't think we need to change that. connect() should 
> never block for 1 minute- while the TCP specs allow for upto 
> 2 minutes, this is hardly ever the case. the latency from one 
> corner of the earth to the other is hardly over a few 
> seconds. the only way that a connect would block for so long 
> is if you either have a terribly malfunctioned server or you 
> are trying to connect to a port blocked by a firewall with a 
> DROP policy - either case the configuration is not valid, so 
> I don't think we should program Kannel to work with it, and I 
> personally would prefer that my system would get stuck on 
> such cases as that would alert me that something in my setup 
> is broken.
> > 
> > --
> > Oded Arbel
> > m-Wise mobile solutions
> > [email protected]
> > 
> > +972-9-9581711 (116)
> > +972-67-340014
> > 
> > ::..
> > Von Neumann was the subject of many dotty professor 
> stories.  Von Neumann
> > supposedly had the habit of simply writing answers to 
> homework assignments on
> > the board (the method of solution being, of course, 
> obvious) when he was asked
> > how to solve problems.  One time one of his students tried 
> to get more helpful
> > information by asking if there was another way to solve the 
> problem.  Von
> > Neumann looked blank for a moment, thought, and then 
> answered, "Yes.".
> > 
> > 
> 
> 
> -- 
> Vjacheslav Chekushin                                mailto:[email protected]
> Latvian Mobile Phone Company                        http://www.lmt.lv
> 
>