TCPIP SS$_IVBUFLEN problem

[TedMaringer]

I have a program which uses SYS$QIO system services (IO$_WRITEVBLK and IO$_READVBLK) to
send TCPIP messages back and forth. The problem occurs when I try to increase the length of the message to more than 32767 bytes.
The IOSB status block returns the SS$_IVBUFLEN error code. What do I need to do to be able to increase the size of the message? Is this being limited by a process quota, system quota, or TCPIP parameter? I have not been able to find the correct parameter to change. I am running OpenVMS 7.3-1 on an Alpha ES40.

[Hein van den Heuvel]

It would not surprise me if that was simply the max. The receiver/sender will have to learn how to break up a message.

It might depend on the IP stack being used.
UCX? Multinet? ...

Finally it could be a programming error where a signed short is used to store / move the length arounf in which case anything over 32767 becomes negative.
Try unsigned!?

What language?

hth,
Hein.

[Hoff]

TCP connections are streams of data, and are not record-oriented transfers. This can lead to some quite confusing -- but correct behavior when the messages are delivered. This really gets weird when you're dropping "datagrams" into an unintialized buffer.

You can send a single TCP write I/O containing the buffer:

[This is my message]

and the receiver might encounter a sequence of reads such as the following:

[This][ ][is my mess][age]

Just toss what you need in how ever many messages you need, in other words. It's the receiver's job to re-package it all.

Prior to TCP/IP Services V5.5 (IIRC), the BG device I/O maximum transfer size limit is 64K, and further limited by the process BYTLM quota and the system MAXBUF parameter setting. Again, IIRC. But do remember that the TCP recipient (still) has to reassemble the "datagram" in any case.

Stephen Hoffman
HoffmanLabs

[TedMaringer]

I am using TCPIP Services for OpenVMS V5.3-04. One VMS program that sends and receives messages to another VMS program is written in Fortran. Another program that receives from the VMS program and also sends and receives from a Windows platform is written in C. The software is from a third party vendor which provided the source. It looks like that I will need to develop a strategy to break up the messages into parts in order to send a large amount of data. Thanks for your help.

[Hoff · Accepted solution]

Expect to receive those packet fragments, too.

This is a very common TCP coding mistake, and the errors -- when a packet arrives in fragments -- can be very obscure.

For additional details on this, you can find:
http://h71000.www7.hp.com/openvms/journal/v3/tcpip.html
has a brief discussion of this in its:
"TCP Data Transfer â Stream of Bytes"
section.

[Chris Wesling]

I've been having the same problem as the original poster. I'd already guessed that it might be related to the TCPIP version, because it occurs on a system that has VMS 7.3-2 and TCPIP 5.4, but not on a system that has VMS 8.2 and TCPIP 5.5. Thanks for confirming that, Hoff!

Question: can a VMS 7.3-2 system be upgraded with TCPIP 5.5? Or is the TCPIP version tied to the VMS version?

[Richard J Maher]

Hi,

Just to pick up on what Hoff was saying, ucx$c_msg_blockall is definitely your friend.

Also for an example of piecing messages together please see the CLIENT_RECV program in the attached COBOL source.

The message format convention has the first 2 bytes identifying the browser tab that contains the JavaScript "callback" function to process the response, and the next 4 bytes are the message length (followed by the actual message). The client_recv sub-program returns control until Tier3 has received at least a complete header (6 bytes) and then however many bytes were in the length.

If there is any residue in the buffer after processing the first message(common with event driven clients queueing up requests) then server-affinity is retained for the next request (Quite a nice optimization)

When a complete message is available the Process_Msg sub-program is called.

This is an example-in-progress as I'm working on something to demo our new SSO multi-tab multi-webpage Tier3Client Applet, and may have no relevance to what you are doing, but it does highlight the issues Hoff was discussing.

Cheers Richard Maher

[Hoff]

Per the published product documentation, both TCP/IP Services V5.5 and V5.6 minimally require OpenVMS Alpha V8.2.

OpenVMS Alpha V8.3 has been out for three years.

It's time to upgrade.

[Chris Wesling]

Yeah, I just found that requirement in the release notes for TCPIP 5.5. Rats.

Unfortunately, all our software clients are hospitals, so they tend to be very resistant to OS upgrades due to fear of messing up a working system. I think it was only within the last year or two that we got all of them up to VMS 7.3 or higher! So it sounds like I'll probably have to rewrite my code to break up the messages into 64K chunks, to allow use with TCPIP 5.4.

Is there some way my program can find out which version of TCPIP is currently installed? Then at least it wouldn't have to chunkify the messages unless it needs to. I haven't found anything in the documentation yet about finding the version number.

[David Jones_21]

The code should have been using a loop to begin with and assuming that WRITEVBLK only sent the number of bytes returned in the second word of the IOSB.

If you are using a regular ethernet for the network, the MTU will be 1500 bytes. The kernel is going to break up your 32K write into over 20 IP datagrams anyway, so you get diminishing returns with super-sized writes.

If you want to make it adaptive to the version, the only thing I can think of is to set the max write to 2GB in your loop and if you can an IVBUFLEN, set the max write to 32767 and treat as zero bytes written for that pass through the write loop. There is the complication that which part of the IOSB you check depends upon how many bytes you tried to write (use second longword if over 65K, second word otherwise).

[Richard J Maher]

Don't know where it went the first time. Anyway, here's the attachment I spoke about.

Cheers Richard Maher

[Hoff]

With a comparatively (and entirely reasonably) conservative customer base, you're going to double your code paths and better than double your testing requirements with a version-based conditional? That seems, well, odd.

Loop the receiver. Contend with "partial" messages. That's how TCP works.

Why don't I like extra and conditional code paths here? Networks and network failures are not fun. The bizarre and degenerate networking cases seemingly always happen with irreproducible and transient configurations and marginal bandwidth levels and only at customer sites with weird or faulty or edge connections and odd loads and in the middle of the night when no instrumentation is working; the "best" of these failure cases are irreproducible. So I try to avoid creating additional cases.

Where available, the use of network-level middleware to deal with the communications can be beneficial. I know how to use TCP. Been using it for a very long time. And it still goes off the rails; networks are like that.

If you're working with transactions within your own network protocol, I can pass along some pointers to algorithms that work reasonably well for contending with network failures.

To answer your direct question, I don't know of a documented API to retrieve the IP stack version at run-time, but there are certainly various "indirect" ways to determine the version.

[Chris Wesling]

That makes perfect sense, so I'll avoid conditional processing. As you can probably tell, I'm quite new to TCP programming; the original program I'm working on was written by somebody else in our organization some years ago.

Our main SE seems to think we might be able to mandate an upgrade to VMS 8.2 after all, so I'm waiting for word on that before I start rewriting anything. Did TCPIP 5.5 remove the 64K limit altogether, or simply raise it to something much higher? I may still have to chunkify things if our longest possible message exceeds a new, higher limit.

[Chris Wesling]

Re David's comments: Sorry if I misled, but the code actually is looping already. The first 6 bytes of the messages we receive specify the total length of the message, so we specify that as the maximum buffer length in the calls to $QIO. After each READVBLK operation, we check how many bytes were actually returned by that call, copy them to our main buffer, and subtract that from the max length; if the max length now equals 0, we know we're done, otherwise we loop again.

The trouble is, with TCPIP 5.4 you can't specify a maximum buffer length greater than 64K without getting an IVBUFLEN, and the max message length being sent to us is 999,999. So I think I'll have to do a sort of loop within the loop to read up to 999,999 bytes 64K at a time. Or maybe just change the way we handle the max buffer length.

[Hoff]

64 limit?

You're (still) thinking of packets and messages.

It's a stream. A hose. A pipe.

You shove enough of your ground up bits into one end of the TCP machinery, and slice off the hunks of sausage that eventually get extruded at the other end of the pipe. Much like making sausage, you might have to plunge the intake a few times to fill the sausage, too. Or you might end up with a few runt sausages, if you're not careful.

if you want to work with datagrams, messages and packets and such (and not the sausage factory that is TCP), then UDP or raw Ethernet traffic or such will be your friend.

Or look to middleware.

[Richard J Maher]

Hi,

In case nobody has used the previously mentioned ucx$c_msg_blockall (or the io$m_lockbuf function modifier) I've attached an example of retrieving a fixed-length header followed by a variable number of bytes here. (I find it useful)

As far as TCP/IP services supporting longword lengths, I have to say I'm behind the times. Does someone have a pointer to the release notes for this? I looked in 5.5 and couldn't see it?

How did they get 32 bits into the 16 bit len in the iosb? How do you request the new behaviour? Is there a flag like io$m_extend? IPv6? Is Process Software on board with their _BG: driver for Multinet and TCPware?

Buffer vectors?

Cheers Richard Maher