SYS$QIOW

[Rizwan Latheef]

Iam using sys$qiow to read messages from the TCP socket. I read the message do some processing and then send the response back and close the socket. Now after I send the response back I have to receive another message and do futher processing before closing the socket. Do I have to do an another SYS$QIOW read to read the second time or will the message end up at the first sys$qiow call?

[Steven Schweda]

Wnen you do a QIO[W] read operation, it tells
you how many bytes you got, and what those
bytes are. If you want more bytes, you need
to do another read operation.

> [...] or will the message end up at the
> first sys$qiow call?

Messages go to buffers, not to function calls.
Do you mean, "Will the new bytes (for which I
haven't asked) magically appear somewhere in
some buffer, updating a byte count, one or
more status values, and various other things
in other places?" No, I don't think so.

[Robert Gezelter]

Rizwan,

At a minimum, the call to SYS$QIOW must be executed a second time. Once an IO operation has completed, it is finished.

Your code can certainly re-execute the SYS$QIOW call, provided that all of the parameters are appropriate.

I would suggest examining some of the examples in the documentation set for both TCP package and the general OpenVMS documentation kit.

- Bob Gezelter, http://www.rlgsc.com

[Dean McGorrill]

Theres usually good examples in the
sys$examples area under tcpip, that show
qio processing. Dean

[Hoff]

If you're familiar with it, $qio[w] is equivalent of ioctl or other low-level I/O call. For most cases, $qio[w] is a one-shot operation. And yes, you'll need to requeue for each wad of data. Various folks will code this sequence as an AST-based loop.

One subtlety of TCP and messages; you must be careful with the concept of packets or messages.

Within TCP, there are no units of "packets." There are no "messages." Meaning you might have to perform multiple $qio[w] calls to (re)assemble what you want to process as a message.

TCP is a stream of data, and you might get a single byte at a time, or you might get multiples of your messages. Don't treat it and don't assume it's a datagram protocol. Subtle errors can arise if you do.

This behavior is expected and intentional, but only tends to show up when the application or the system or the network is under stress. And if the application isn't coded to deal with the characters, you can end up with "torn" or otherwise corrupted "messages."

[John Gillings]

Rizwan,

It sounds to me like you're venturing into the exciting and potentially confusing world of "network protcols". That is, following a set of rules for a "conversation" between two systems exchanging messages. The BIG trick here is to know when to talk, when to listen, and how or when to decide that the party at the other end of the wire isn't following the rules.

Although it may SOUND simple enough, it isn't! What if you issue your $QIOW and the other end doesn't send anything? You just hang there waiting forever.

Sometimes it's simpler to code this kind of exchange as multi threaded, full duplex, listening at all times. Instead of $QIOW, use $QIO with a completion AST. That way your application isn't hanging around waiting, and you can handle unexpected messages arriving. On the other hand it does require careful coding.

At the very least, you should add a timeout to your reads to prevent waiting forever. Get hold of a textbook on network protocols so you can discover some of the tricks and traps, rather than discovering them for yourself.