| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5031.1 | same question | SYSTEM::ROGGENSTEIN | | Thu Dec 19 1996 08:35 | 13 |
| 5031.2 | Be careful here... | ucxaxp.ucx.lkg.dec.com::TIBBERT | Lee Tibbert, DTN 226-6115 | Thu Dec 19 1996 14:55 | 10 |
| 5031.3 | | CSC32::D_DERAMO | Dan D'Eramo, Customer Support Center | Thu Dec 19 1996 18:15 | 767 |
| 5031.4 | Thanks | METSYS::ROGGENSTEIN | | Mon Jan 06 1997 09:28 | 4 |
| 5031.5 | socket and channel relationship | 43945::HELLIAR | http://samedi.reo.dec.com/ | Tue Apr 29 1997 10:45 | 20 |
| Hi,
What's the relationship between a 'socket' and the 'channel' used by
the QIO example's above?
We're using the socket interface everywhere else, so ideally, having
got and assigned to the relevant 'BG' unit I would like to revert to
using a socket id.
Can this be done, or have I got to use QIO's throughout?
I tried using bind, listen, and accept on the VMS platform and it got
the request fine. However, if I try using the socket returned from the
accept as the 'channel' to get the BG unit I get LIB$GETDVI failing
with
SYSTEM-F-IVIDENT, invalid identifier format
Thanks in advance,
Graham
|
| 5031.6 | Try documentation for decc$get_sdc() | LADDIE::TIBBERT | Lee Tibbert, DTN 226-6115 | Tue Apr 29 1997 19:52 | 10 |
|
Without endorsing either sharing of sockets or switching
between sockets and channels....
Look at the documentation for DECC$GET_SDC() under
help socket decc$get_sdc.
Use at your own risk,
Lee
|
| 5031.7 | But what about channel to socket | 43945::HELLIAR | http://samedi.reo.dec.com/ | Wed Apr 30 1997 05:49 | 7 |
| DECC$GET_SDC gets a VMS channel from the socket descriptor. However, in
the socket sharing example, I need the child to assign to the BG device
and then start doing 'normal' socket operations.
SO, I need some way of going from VMS channel to socket descriptor.
Any takers?
|
| 5031.8 | Possible, but not easy | LADDIE::TIBBERT | Lee Tibbert, DTN 226-6115 | Wed Apr 30 1997 10:24 | 12 |
|
Re: channel to socket.
I suppose that channel to socket could be done with
sufficient knowledge of UCX and DEC C RTL internals, but
it is almost certainly unsupported.
Wouldn't it be way easier to code this thing right from
the beginning (where right is defined as no socket sharing) ;-)
Lee.
|
| 5031.9 | What is right on VMS, may not be right elsewhere! | 43945::HELLIAR | http://samedi.reo.dec.com/ | Wed Apr 30 1997 13:52 | 18 |
| Lee,
Im just going by what people tell me is the 'right' way to do things.
Getting a child to service the request so the parent is ready to
'catch' the next request comes about because the standard sockets have
a small 'queue' and so client requests can fail because the parent cant
service their request quick enough. At least this is the story I was
told for Digital Unix.
At the end of the day, it seems that since we're stuck with our current
parent/child architecture and that VMS can only hack this using
platform specific implementation via VMS devices and channels then I'll
have to use QIO's thoughtout.
Regards,
Graham
|