[Info-vax] ODS5 on Linux

[David Froble]

johnson.eric at gmail.com wrote:
> On Wednesday, May 16, 2012 2:17:21 PM UTC-4, David Froble wrote:
>  
>> Aside with putting up with the deficiencies in HP TCP/IP, I'm getting
>> slightly decent with socket communications.
> 
> By deficiencies, are you referring to the slow performance?  I've always found the TCP/IP stacks on VMS to be incredibly sluggish.  It's not just a bandwidth problem, it's very slow (relatively speaking) at reading and sending very small packets.  The situation on a platform like Linux is quite different.  It's very tragic.
> 
> EJ

Ooops!  Possibly a bad question.  If I don't contain myself, there might result a rant of 
epic proportions on c.o.v ....

The HP TCP/IP stack is basically a port of a Unix (T64) product.  As such it seems to want 
to do things in a Unixy manner.  One of those Unixy things is the concept of a Inet damon 
(demon) that wants to intercept all connection requests and create a process to accept the 
connection.  On VMS this piece of shit is called the auexlery processor (see, I hate the 
concept so much I cannot spell it).

I've had applications running for years now, that streamed the connections one at a time. 
  But now we're looking at increased traffic, and I feel that streaming connections in 
such a manner will in time give us a serious bottleneck.

As for your  question, performance is not an issue.  We're servicing connection requests 
in fractions of a second.  But that really depends upon what the application needs to do 
to service the request.  For an inventory stock inquiry, we can reply to a list of a 
hundred parts in a fraction of a second.  Some other types of requests take a few seconds, 
but as I wrote, that's the application, not TCP/IP.

What really burns me is, when a listener gets a connection request, and you grant the 
connection, it does it on THE SAME SOCKET THAT WAS LISTENING !!!  No chance to work with 
the client while going back to listening for another connection request.

I've seen much better, and brace yourself Brian, it was a Weendoze 3rd party product.

If I mentioned the problems with getting this to work with the HP port of OpenSSL, the 
rant would grow far beyond epic.

Anyway, I guess that much of this is basically that if I was implementing socket 
communications, the design would be different.

As for Process, I mentioned my problem to Hunter, and he never got back to me, so I'm 
wondering if their TCP/IP stacks have the same problem.