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, -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si |
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? > 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/ |
On Dec 18, 2007 1:05 AM, Cesar Rabak <[hidden email]> wrote:
Janko Mivsek escreveu: Cesar, I'm a bit lost on this report of yours: 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 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 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 |
Free forum by Nabble | Edit this page |