- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: TCPIP SS$_IVBUFLEN problem
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-12-2009 12:37 AM
тАО08-12-2009 12:37 AM
Re: TCPIP SS$_IVBUFLEN problem
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-12-2009 04:40 AM
тАО08-12-2009 04:40 AM
Re: TCPIP SS$_IVBUFLEN problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-13-2009 02:26 PM
тАО08-13-2009 02:26 PM
Re: TCPIP SS$_IVBUFLEN problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-13-2009 02:41 PM
тАО08-13-2009 02:41 PM
Re: TCPIP SS$_IVBUFLEN problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-13-2009 02:50 PM
тАО08-13-2009 02:50 PM
Re: TCPIP SS$_IVBUFLEN problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-14-2009 09:18 PM
тАО08-14-2009 09:18 PM
Re: TCPIP SS$_IVBUFLEN problem
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
- « Previous
-
- 1
- 2
- Next »