connect(): Operation already in progress

[Alejandro Rosales]

Hello people,

I was hoping you could shed some light on a subject I don't quite master.

I have this provider, who is developing an application for my company. In an overall, it's composed of a central server (Currently a 9000 K Class) and several workstations spread over the WAN. (Visualize Workstations). Both, server and workstations running 11.00

The provider constantly calls for support from our networking and telecomms team, arguing that "the net isn't working". I have done the due tests (latency, loss, sniffin' it all and putting it back together), and there is no such slowliness they're talking about.

Anyway, maybe I got a little off topic, but my question is this:

I can see on the main server a massive flow on the console, logging:

Connect: Operation already in progress.
accept_socket: Operation would block.

I must say, the second line "accept_socket" is not displayed saying exactly that, but I can't exactly recall the function name originating the [EWOULDBLOCK].

As far as I know, "Operation already in progress" is the string description for the[EALREADY] error in /sys/socket.h's connect(),
and "Operation would block" is the one for [EWOULDBLOCK] error in /sys/socket.h's accept().

My best bet is that the program isn't healthily connecting through the network, and I would really appreciate it if someone could point me to the possible causes of this. Is the application's network routine all messed up? or should I tune one of the server's TCP/IP parameters (via ndd) so that this does not happen?.

My concern is with stretching TCP/IP just to "silent" an unefficient program.

Are there any other places to look for, regarding the causes of the [EALREADY] and [EWOULDBLOCK] errors?.

Any insight would help.

Many thanks in advance.

[Steven E. Protter · Accepted solution]

Some of those old Visualize workstations they require a network connection 10 BaseT manual.

Auto negotiate can cause these type of problems.

SEP

[Alejandro Rosales]

Thanks for that.

I gather it can also happen because of port speed, and will thoroughly check it too(Workstations are at a different place in the country at the moment.)

Any more insight available? Like a log I'm missing? or something? (As I said, it can't just judge the application without checking out the essentials first and making sure environment is ok).

[A. Clay Stephenson]

By all means check the network speed/duplex setting but if you can put/get a 1MB file in both directions are perhaps 1/3 of the rated throughput for the connection then that is not your problem.

My best guess is connect() is behaving exactly right. I suspect that your application is using t_open() or open() and the socket is setup to be non-blocking. These errno's simply mean that a previous operation has not completed or that a connection is already established. In that case, the application should retry after a delay.

[A. Clay Stephenson]

By the way, you might have your developer think about using Perl. Using the IO::Socket module, one can do some amazingly complex tasks that once I would only have considered doing in C. I find that I can put together a sockets-based application complete with real signal handlers in a fraction of the time the same effort required in C. If you already are familiar with sockets, the Perl codes very much like the C --- only about 10x faster and will run unchanged on UNIX and Windows.

[Alejandro Rosales]

Thanks for your reply A. Clay.

Indeed, maybe the network routines are using t_open() or open() strictly, or the socket is set to non-blocking.

Yes, it's up to the application to efficiently handle the delay.

Your feedback (yours too Steven) is very useful as I have now more info to dig and reach a decision.

About using Perl, it'd certainly be more efficient, but the development has already been going on for a long time, and they are using a development environment, where they just have to plan and care about the process flow rather than playing directly with the socket functions themselves.

Just pointing out our situation, (not ranting), and I agree with you about such better alternative.

Thanks a lot.

[Alejandro Rosales]

Um... I have submitted thrice the point assignment, but to no avail. I will keep trying until it does submit them, don't think I've forgot about your earned points!.

[Steven E. Protter]

Looks like you got those points assigned.

To add something that should have been in my original post.

Whatever switch you are going through must NOT be Auto Negotiate on those old workstations. Unless you are talking 1000 BaseT, it is good practice to use explicit port set up for all HP-UX NIC cards.

The only instance where I've gotten away with auto negotiate is with a D320 in my basement(educational tool) and a Dell 2124 switch. I'm still waiting for the other shoe to drop on that one.

SEP