| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 31-JAN-1997 16:51:30.71
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: RE: POINT No.18545, BBP, non-blocking sockets
Hello Nick Smith,
>He has developed an API on UNIX he is now porting to VMS. He has TCP/IP
>V4.0.
>He needs to know how to set the application to accept the socket code in
>non-blocking mode.
This should be possible on VMS; I think there are a couple of ways to do it
depending on how much code changing you want to do.
I expect you will want to use code similar to the Unix version, in which case
you should be able to call ioctl() to set the socket non-blocking. However,
ioctl() isn't in the standard C RTL yet, and so in the meantime a version has
been provided that you can use in:
UCX$EXAMPLES:UCX$IOCTL_ROUTINE.C
Which I think should give you the functionality you need.
For a more VMS-ish approach, you could use the $QIO interface, as documented in
the "System Service and C Socket Programming" manual which you can find in
the "Telecommunications and Networking\Digital TCP/IP Services for OpenVMS"
bookshelf in the Bookreader docs.
For example, for a read operation, you would use the function code IO$_READVBLK
and a modifier of UCX$C_MSG_NBIO to read asynchronously from a socket.
Let me know if this is enough to get you going or if you need more help (in
which case perhaps you could provide a bit of detail on what it is you're
doing)
Regards
Nick Hudson
Digital Software Partner Engineering
|
| From: VBORMC::"[email protected]" "Nick Smith" 31-JAN-1997 18:29:31.47
To: [email protected]
CC: [email protected]
Subj: RE: POINT No.18545, BBP, non-blocking sockets
> From [email protected] Fri Jan 31 18:00 MET 1997
>
> Hello Nick Smith,
>
> >He has developed an API on UNIX he is now porting to VMS. He has TCP/IP
> >V4.0.
> >He needs to know how to set the application to accept the socket code in
> >non-blocking mode.
>
>
> This should be possible on VMS; I think there are a couple of ways to do it
> depending on how much code changing you want to do.
>
> I expect you will want to use code similar to the Unix version, in which case
> you should be able to call ioctl() to set the socket non-blocking. However,
> ioctl() isn't in the standard C RTL yet, and so in the meantime a version has
> been provided that you can use in:
>
> UCX$EXAMPLES:UCX$IOCTL_ROUTINE.C
>
> Which I think should give you the functionality you need.
>
Yes it does, although the arguments required to set the socket to
non-blocking are little obscure. The big problem is athat this
implementation of ioctl() uses a QIO with the function code parameter set
to UCX$C_IOCTL. Using this function code requires SYSPRIV, BYPASS or OPER
privilege (see $QIO/IO$_SETMODE/IO$_SETCHAR page in the TCP/IP bookshelf).
As you can understand this not possible in 99% of cases.
> For a more VMS-ish approach, you could use the $QIO interface, as documented in
> the "System Service and C Socket Programming" manual which you can find in
> the "Telecommunications and Networking\Digital TCP/IP Services for OpenVMS"
> bookshelf in the Bookreader docs.
>
Yes, I've looked at this bookshelf but I cannot find how to set a socket to
non-blocking with a QIO *anywhere*. The reason for this is that you do
not need to set a VMS channel to non-blocking, using a QIO instead of
QIOW is the normal solution.
I could of course use a SYS$QIO to do the accept(), and then use SYS$WFLOR
or similar to wait for the incoming connect. This of course introduces
a lot of VMS specific code into my 'portable' library as I currently use
select() to detect incoming data and connections.
As most customers want do an 'accept() with timeout' I could use SYS$SETIMR,
with an AST routine to cancel the accepting QIO and visa versa. This is a
possible solution but also undesirable.
> For example, for a read operation, you would use the function code IO$_READVBLK
> and a modifier of UCX$C_MSG_NBIO to read asynchronously from a socket.
>
Correct, I found this out after a long study of the bookshelf but I cannot
find a similar caveat to allow me to do a n.b. accept().
> Let me know if this is enough to get you going or if you need more help (in
> which case perhaps you could provide a bit of detail on what it is you're
> doing)
>
Could you please have another look before I have to use QIO / WFLOR.
Here follows a summary (???) of what I am trying to achive.
We have products that run on various platforms (VMS (VAX/AXP) and various
UN*X flavours. These products are message handling systems. They are
used to interface Swiss banks back-office systems to the Swiss money and
share trading networks.
We have in the past implemented various links to the bank's host machines
(DECnet/X.25 for VMS hosts, SNA/X.25 for MVS machines and TCP/IP for the
UN*X hosts). Now the banks using VMS and MVS hosts are requesting TCP/IP
links to their hosts.
We regulary supply customers with an API that implements our message passing
protocol to our customers to aid intergration. The TCP/IP API has already
been produced on UN*X and MVS. Now a customer with a VMS host wants this
API. Unfortunately this customer wants the host to be the server side
which means performing an asynchronous accept() call.....
> Regards
>
> Nick Hudson
>
> Digital Software Partner Engineering
>
Many Thanks for your Help.
--
Nick Smith - Software Engineer - Biveroni Batschelet Partners - Switzerland
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA22872 for
<[email protected]>; Fri, 31 Jan 1997 19:26:19 +0100
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA28149 for
<[email protected]>; Fri, 31 Jan 1997 19:31:05 +0100 (MET)
% Received: from mail.eunet.ch (mail.eunet.ch [146.228.10.7]) by
server21.digital.fr (8.7.5/8.7) with ESMTP id TAA28978 for
<[email protected]>; Fri, 31 Jan 1997 19:32:56 +0100 (MET)
% Received: from bbp.ch by mail.eunet.ch (8.8.3/1.34) id SAA13430; Fri, 31 Jan
1997 18:26:08 GM
% Received: by bbp.ch (SMI-8.6/SMI-SVR4) id TAA29518; Fri, 31 Jan 1997 19:25:55
+010
% Date: Fri, 31 Jan 1997 19:25:55 +0100
% From: [email protected] (Nick Smith)
% Message-Id: <[email protected]>
% To: [email protected]
% Subject: RE: POINT No.18545, BBP, non-blocking sockets
% Cc: [email protected]
% X-Sun-Charset: US-ASCII
|
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 4-FEB-1997 11:42:14.42
To: nm%VBORMC::"[email protected]"
CC: HUDSON
Subj: RE: POINT No.18545, BBP, non-blocking sockets
Hello Nick Smith,
Thanks for the additional mail on sockets, ref asynchronous accept().
Sorry I hadn't spotted the privilege restrictions on the SETMODE.
Being a VMS-y rather than Unix-y person, my natural inclination would be to do
something like:
[main-line code]
set timer to go off in 5 secs
issue QIO to accept
if (stat == ss$_cancel) { nothing came in }
if (stat == ss$_normal) { cancel timer, act on valid accept }
[timer completion ast]
cancel accept QIO.
Which is one of the mechanisms you describe, and one I've used in the past
(although not with sockets).
Looking at the docs and trying to wade through some of the previous
correspondence that others have had on related issues, one of the other things
suggested in order to get an asynchronous accept() is to use a QIO with
IO$_ACCESS, and use the modifiers IO$M_ACCEPT and IO$M_NOW (see TCP/IP Services
manual, section on IO$_ACCESS). This looks more promising, although I've not
experimented with it myself yet.
I realise that neither of these is very portable though.
I will try get some example code for you, but thought I'd send you this info in
case it's of use in the meantime
Regards
Nick Hudson
DIgital Software Partner Engineering
|
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 4-FEB-1997 16:20:24.99
To: nm%VBORMC::"[email protected]"
CC: HUDSON
Subj: RE: POINT No.18545, BBP, non-blocking sockets
Hello Nick Smith,
I found a note where someone's asking a question which I think overlaps with
what you're doing, and includes some sample code.
I've included the relevant bits below. Is this useful?
nick
<extract from #3554 on LASSIE::UCX included>
|