Re: VAX COBOL and TCP/IP
From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 01/25/05
- Next message: XPPROGRAMMER: "Displaying the contents of pointers in cobol..."
- Previous message: Chuck Stevens: "Re: Mainframe Code"
- In reply to: Paul Robinson: "Re: VAX COBOL and TCP/IP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 25 Jan 2005 17:28:12 GMT
In article <gFtJd.9952$Hg6.7236@trnddc09>, Paul Robinson <postmaster@paul.washington.dc.us> writes:
> simon martin wrote:
>
> > The packet structure we are sending is <STX><LENGTH><DATA><ETX>. Send
> > works OK, but the COBOL programmer does know how to do an interative read
> > and store to process the incoming data.
>
> Generally you have to do that when sending data over a modem because you
> don't necessarily know where a packet starts or ends, or what its size is.
>
> This practice is totally unnecessary under TCP/IP because the standards
> automatically indicate what a particular packet is, the order of the
> fragments, and how long it is.
No they don't. TCP is a stream protocol; it provides no delimiting of
user records. UDP is an unreliable-datagram protocol and may silently
truncate or fail to deliver a record.
There have certainly been a great many record-oriented protocols
designed to run on top of TCP/IP, and some of them are even standard
(in the sense of appearing in standards-track RFCs and the like), but
applications using straight TCP have to do some sort of framing.
Using both frame markers (and hopefully some bit-stuffing or other
escaping technique to prevent them from appearing elsewhere in the
data) and a length field is redundant, but redundancy is often a good
idea.
In many cases, application programmers would do better to avoid
reinventing the wheel and use one of the many freely-available
implementations of record-oriented application protocols. Lots of
applications that have nothing to do with web browsing use HTTP for
just this reason, for example.
However, if the OP is committed to using "raw" TCP streams, then he's
on the right track. I didn't see the original post (apparently due
to an infelicitous interaction between a crashing X server, my
newsreader's approach to updating its read-article data, and the
server's article-numbering scheme), but with typical TCP APIs (BSD
sockets, etc) the receiving side would:
1. Make sufficient receive attempts, accumulating data in a buffer,
until the initial fixed-length portion of the message had been read
(in this case, that would be the <STX> and the <LENGTH>, assuming the
latter was fixed-length; if not, this gets a bit trickier, as the
receiver would have to receive data and parse it until it knew it had
the entire length field). Of course, it needs to handle exceptions
such as premature conversation termination.
2. Verify that the <STX> is correct, parse the <LENGTH>, and verify
that it's within an acceptable range. (Skipping the last step is not
a good idea. I've seen plenty of programs that used a 32-bit length
unquestioningly but would never receive a 4 GB packet in proper
operation. Implement sanity checks.)
3. Make additional receive attempts, accumulating data, until the
entire packet has been received. It would be a good idea to scan for
<ETX> after each receive, as another sanity check (assuming <ETX>
cannot appear in normal data).
4. Verify the <ETX>.
Many modern protocols (like HTTP) are much more complex, and can
delimit records in various ways, but the above is pretty typical for
simple proprietary application protocols.
The main thing to note is that TCP does not know where your record
ends, so the TCP API cannot receive your record for you. You have to
determine when you've reached the end.
-- Michael Wojcik michael.wojcik@microfocus.com This is a "rubbering action game," a 2D platformer where you control a girl equipped with an elastic rope with a fishing hook at the end. -- review of _Umihara Kawase Shun_ for the Sony Playstation
- Next message: XPPROGRAMMER: "Displaying the contents of pointers in cobol..."
- Previous message: Chuck Stevens: "Re: Mainframe Code"
- In reply to: Paul Robinson: "Re: VAX COBOL and TCP/IP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
