- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: socket peek buffer sizes
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
тАО02-24-2011 07:03 AM
тАО02-24-2011 07:03 AM
Re: socket peek buffer sizes
Ah, this old chestnut.
As you quite correctly state, TCP provides a stream of data.
And you're presuming to treat that stream as a record device.
It's not, unfortunately.
UDP does give you something closer to the record-oriented model. (Depending on exactly what is going on, UDP multicasts or even raw Ethernet datagrams can be a pretty handy solution to some classes of application problems, but I digress.)
TCP is free to give you 50,000 separate I/Os of 1 byte each or the full 50,000 bytes in one shot. Or 49,999 hits of 1 byte each, and then 50,000 bytes containing the last byte and most of the next transfer. Or any combination between that.
With TCP-based application communications, you get to do the segmentation and window processing in your code. Attempts to use timers to segment TCP traffic into records will tend to combine with the intervening IP routers and switches and other application traffic to conspire to find edge cases in socket code, too.
I'd suggest looking for middleware. Socket-level programming is something like programming assembler. It's possible, functional, feasible and such, but it's usually easier to punt on that and to use available networking libraries and available middleware packages. Rolling your own is something that involves, well, dealing with TCP streams and buffers and such. And you probably have application and customer code to write, rather than all of the glue code involved with socket programming.
If you can't migrate to a middleware interface into the IP network (and there are certainly reasons why VMS application programmers might not find that feasible) then you'll have to deal with the sliding window yourself. It's common to see a 2x buffer (or more) for the reads, and to aim the I/Os at the next available byte in the buffer. Basically assembling the incoming data into the record structures.
Double-buffering a TCP stream gets a little more ugly (and can involve rather more buffer copies than might be pleasant to perform on a busy server), as you don't really know how much you're going to get in response to each read.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 07:12 AM
тАО02-24-2011 07:12 AM
Re: socket peek buffer sizes
The driver does not wait; it just delivers as soon as something shows up, unless I provide the IO$M_LOCKBUF qualifier, in which case the I/O won't complete until I receive all the bytes I ask for or my partner closes the connection. Unfortunately, that's not an option for me.
Thanks for the help. I just wanted an explanation. My code works fine; I just thought I could tweak things a bit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 08:12 AM
тАО02-24-2011 08:12 AM
Re: socket peek buffer sizes
Good ole DECnet made life much easier! A true record oriented protocol.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 08:15 AM
тАО02-24-2011 08:15 AM
Re: socket peek buffer sizes
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 08:22 AM
тАО02-24-2011 08:22 AM
Re: socket peek buffer sizes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 10:12 AM
тАО02-24-2011 10:12 AM
Re: socket peek buffer sizes
To change the default internal read buffer size do a IO$_SETMODE with TCPIP$C_RCVBUF.
I haven't played much with that but I doubt you'll see a significant performance gain with larger RCVBUF values.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 12:00 PM
тАО02-24-2011 12:00 PM
Re: socket peek buffer sizes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 12:42 PM
тАО02-24-2011 12:42 PM
Re: socket peek buffer sizes
Thanks again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-24-2011 03:02 PM
тАО02-24-2011 03:02 PM
Re: socket peek buffer sizes
I never am. ;-)
/Guenther
- « Previous
-
- 1
- 2
- Next »