Re: Read from empty socket - improper closing it

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Read from empty socket - improper closing it

Janko Mivšek-2
I'm more and more inclined to the conclusion that VisualWorks TCP sockets interface is simply not up to the task for serious TCP applications. It simply lacks support for things like closing a connection gracefully, which is a must for applications like a web server having clients connected via proxy servers like Squid.

Namely, Squid requests a connection close shortly after sending a HTTP request. In the meantime server already started responding to that request. Normally a web server ends responding first then it closes its part of connection. But on VW a TCP implementation closes a socket almost immediately when client requests a close. And there is obviously no way to prevent that. What is happening then is that server is interrupted in the middle of the sending and got that famous "broken pipe" error.

So Cincomers, wouldn't be better to solve such a fundamental flaw in VisualWorks first before going further?

Best regards
JAnko

Janko Mivsek wrote:
Hello,

I have now a reproducible problem and TCP trace of a cause of 'Broken pipe' errors I reported a while ago. And it seems it is also related to "Socket is active until what or when thread" started by Bruce a month ago.

Problem is as follows:

   1. I'm waiting on aSocketAccessor readInto:startingAt:for: to receive
      next data
   2. above method is deblocked but returning zero data
   3. if I repeat, it returns immediately, but again with 0 data
   4. I need to close a connection and start again. This can cause a
      socket close before all data is sent, hence a "broken pipes"

It seems that FIN packets cause above problem. FIN packets somehow deblock a waiting method but they shouldn't. They should raise some exception instead.

Here are two traces on Swazoo done with Ethereal, one with above problem, another without.

1. See packet 10 with FIN, causing Swazoo to read an empty packet, then respond with 400 bad request and close connection with a final packet:

No.Source      Destination    Info
76.8.192.250 <http://76.8.192.250>   213.157.239.24 <http://213.157.239.24>  TCP 33438> http [SYN] Seq=0 Ack=0
213.157.239.24 <http://213.157.239.24> 76.8.192.250 <http://76.8.192.250>    TCP http > 33438 [SYN,ACK] Seq=0 Ack=1
76.8.192.250 <http://76.8.192.250>    213.157.239.24 <http://213.157.239.24> TCP 33438> http [ACK] Seq=1 Ack=1
76.8.192.250 <http://76.8.192.250>    213.157.239.24 <http://213.157.239.24> HTTP GET /znamenitosti.html HTTP/1.0
213.157.239.24 <http://213.157.239.24> 76.8.192.250 <http://76.8.192.250>    TCP http > 33438 [ACK] Seq=1 Ack=541
213.157.239.24 <http://213.157.239.24> 76.8.192.250 <http://76.8.192.250>    HTTP HTTP/1.1 200 OK (text/html)
213.157.239.24 <http://213.157.239.24> 76.8.192.250 <http://76.8.192.250>    HTTP "Continuation or non-HTTP traffic
76.8.192.250 <http://76.8.192.250>   213.157.239.24 <http://213.157.239.24>  TCP 33438> http [ACK] Seq=541 Ack=1441
76.8.192.250 <http://76.8.192.250>   213.157.239.24 <http://213.157.239.24>  TCP 33438> http [ACK] Seq=541 Ack=2293
10 76.8.192.250 <http://76.8.192.250>   213.157.239.24 <http://213.157.239.24> TCP 33438>http[FIN,ACK] Seq=541Ack=2293
11 213.157.239.24 <http://213.157.239.24> 76.8.192.250 <http://76.8.192.250>   HTTP HTTP/1.1 400 Bad Request
12 213.157.239.24 <http://213.157.239.24> 76.8.192.250 <http://76.8.192.250>   TCP http>33438[FIN,ACK] Seq=2714Ack=542

2. Swazoo session without problems:

No.Source      Destination     Info
212.18.33.254 <http://212.18.33.254>  213.157.239.24 <http://213.157.239.24>  TCP  1855 > http [SYN] Seq=0 Ack=0
213.157.239.24 <http://213.157.239.24> 212.18.33.254 <http://212.18.33.254>   TCP  http > 1855 [SYN,ACK] Seq=0 Ack=1
212.18.33.254 <http://212.18.33.254>  213.157.239.24 <http://213.157.239.24>  TCP  1855 > http [ACK] Seq=1 Ack=1
212.18.33.254 <http://212.18.33.254>  213.157.239.24 <http://213.157.239.24>  HTTP GET /znamenitosti.html HTTP/1.1
213.157.239.24 <http://213.157.239.24> 212.18.33.254 <http://212.18.33.254>   TCP  http > 1855 [ACK] Seq=1 Ack=532
213.157.239.24 <http://213.157.239.24> 212.18.33.254 <http://212.18.33.254>   HTTP HTTP/1.1 200 OK (text/html)
213.157.239.24 <http://213.157.239.24> 212.18.33.254 <http://212.18.33.254>   HTTP Continuation or non-HTTP traffic
212.18.33.254 <http://212.18.33.254>  213.157.239.24 <http://213.157.239.24>  TCP  1855 > http [SYN] Seq=0 Ack=0
213.157.239.24 <http://213.157.239.24> 212.18.33.254 <http://212.18.33.254>   TCP  http > 1855 [SYN,ACK] Seq=0 Ack=1
10 212.18.33.254 <http://212.18.33.254>  213.157.239.24 <http://213.157.239.24> TCP  1855 > http [ACK] Seq=1 Ack=1
11 212.18.33.254 <http://212.18.33.254>  213.157.239.24 <http://213.157.239.24> HTTP GET /screen.css HTTP/1.1
...etc


I hope this will shed a light on that problem to help it solve as soon as possible.

Janko

-- 
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
Reply | Threaded
Open this post in threaded view
|

Re: Read from empty socket - improper closing it

Cesar Rabak
Janko Mivsek escreveu:

> I'm more and more inclined to the conclusion that VisualWorks TCP
> sockets interface is simply not up to the task for serious TCP
> applications. It simply lacks support for things like closing a
> connection gracefully, which is a must for applications like a web
> server having clients connected via proxy servers like Squid.
>
> Namely, Squid requests a connection close shortly after sending a HTTP
> request. In the meantime server already started responding to that
> request. Normally a web server ends responding first then it closes its
> part of connection. But on VW a TCP implementation closes a socket
> almost immediately when client requests a close. And there is obviously
> no way to prevent that. What is happening then is that server is
> interrupted in the middle of the sending and got that famous "broken
> pipe" error.
>
> So Cincomers, wouldn't be better to solve such a fundamental flaw in
> VisualWorks first before going further?
>
Janko,

I'm a bit lost on this report of yours:

What's the difference between "...requests a connection close
shortly..." and "...closes a socket almost immediately..."?

Also this phrase bothers me: "And there is obviously no way to prevent
that."

How could Cincom solve "such a fundamental flaw" if "there is no way to
prevent that"?

I'm puzzled!

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

Reply | Threaded
Open this post in threaded view
|

Re: Read from empty socket - improper closing it

Janko Mivšek-2
On Dec 18, 2007 1:05 AM, Cesar Rabak <[hidden email]> wrote:
Janko Mivsek escreveu:
> I'm more and more inclined to the conclusion that VisualWorks TCP

> sockets interface is simply not up to the task for serious TCP
> applications. It simply lacks support for things like closing a
> connection gracefully, which is a must for applications like a web
> server having clients connected via proxy servers like Squid.
>
> Namely, Squid requests a connection close shortly after sending a HTTP
> request. In the meantime server already started responding to that
> request. Normally a web server ends responding first then it closes its
> part of connection. But on VW a TCP implementation closes a socket
> almost immediately when client requests a close. And there is obviously
> no way to prevent that. What is happening then is that server is
> interrupted in the middle of the sending and got that famous "broken
> pipe" error.
>
> So Cincomers, wouldn't be better to solve such a fundamental flaw in
> VisualWorks first before going further?
 

Cesar,

I'm a bit lost on this report of yours:

What's the difference between "...requests a connection close
shortly..." and "...closes a socket almost immediately..."?

You need to read above two sentences in a whole context to see what I meant:
1. Squid requests a connection close shortly after sending a HTTP request.
2. But on VW a TCP implementation closes a socket almost immediately when client requests a close.
 
Also this phrase bothers me: "And there is obviously no way to prevent
that."

Again from a whole context: this is meant that you don't have means to prevent that.
 
How could Cincom solve "such a fundamental flaw" if "there is no way to
prevent that"?

So, if Cincom provides means, then you can prevent that. By means I suggest at least raising an exception when other side requests a connection close.  And maybe they can look at Squeak sockets implementation, which is not perfect but way better and more complete that VW's.


Best regards
JAnko

-- 
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si