Operating System - OpenVMS
1752579 Members
4707 Online
108788 Solutions
New Discussion юеВ

Re: TCPIP SS$_IVBUFLEN problem

 
SOLVED
Go to solution
Richard J Maher
Trusted Contributor

Re: TCPIP SS$_IVBUFLEN problem

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

Cheers Richard Maher
Hoff
Honored Contributor

Re: TCPIP SS$_IVBUFLEN problem

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
New Member

Re: TCPIP SS$_IVBUFLEN problem

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
New Member

Re: TCPIP SS$_IVBUFLEN problem

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
Honored Contributor

Re: TCPIP SS$_IVBUFLEN problem

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
Trusted Contributor

Re: TCPIP SS$_IVBUFLEN problem

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