[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEC TCP/IP Services for OpenVMS |
| Notice: | Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System |
| Moderator: | ucxaxp.ucx.lkg.dec.com::TIBBERT |
|
| Created: | Thu Nov 17 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5568 |
| Total number of notes: | 21492 |
5455.0. "multiple writers on same socket?" by CSC32::J_HENSON (Don't get even, get ahead!) Fri Apr 18 1997 16:11
ucx v4.0, ovms v6.2, alpha, $qio i/f
This has probably been asked and answered before, but I can't find it
if it has. So, I'll ask again.
A customer has written a tcp server, using the $qio interface, that
does the following.
1) binds, listens, etc., and then accepts a connection. After the
connection is made, it spawns (forks) two sub-processes (child
processes). It also sets the connection to be shared.
2) the first child connects to the socket and becomes the sole writer.
It only writes to the client.
3) the second child connects to the socket and becomes the sole reader.
it does not write at all.
They do it this way for reasons I don't understand, but there's nothing
I can do about that. And, they're happy with the way it works, so I
guess it's as good a scheme as any.
Now, they need to modify the reader child to occassionally write. They
explained it to me as sending an occassional acknowledgement. Their
concern is what will happen if the two children processes write at the
same time. Will the messages get intermingled, and require extra
logic to keep straight, or is there a way to force the writes to be
atomic and not allow any intermixing of the messages? Is it even
a problem?
For now, the only suggestion that I'm confident in giving is to have the
occassional writes send out-of-band data, which means that the client will
have to be modified to look for and read oob data. I'm not sure that this
is possible, as I don't believe that my customer controls the client
code.
Am I way off base here, or is this a legitimate concern? And if it is,
are there any socket settings or io$_writevblk modifiers that will
handle this?
Thank,
Jerry
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5455.1 | | CSC32::J_HENSON | Don't get even, get ahead! | Fri Apr 18 1997 16:14 | 8 |
| >> <<< Note 5455.0 by CSC32::J_HENSON "Don't get even, get ahead!" >>>
>> -< multiple writers on same socket? >-
What about using the lock manager or common event flags or something
similar to make sure that one process does not write while the other
does. Would that insure that messages don't get intermingled?
Jerry
|
| 5455.2 | Why do people hurt themselves? | LADDIE::TIBBERT | Lee Tibbert, DTN 226-6115 | Fri Apr 18 1997 18:28 | 22 |
|
Sounds to me that the customer is setting up a situation
sure to cause pain to them. Will DIGITAL be able to charge
to straighten out the situation or will we have to do it
as a freebie?
I myself have always gone by the rule: one socket, one thread.
That is a stricter interpertation of the rule: one socket, one
process.
Some one on UCX kernel team may be able to give you the ins and
outs of what they ask is _possible_. IMHO, it certainly is not
wise.
It involves some redesign and overhead, (hey, they are doing two
process creations already for what should be two threads in a process,
so what the heck), but could they have one process/thread managing
the socket. Then each process/thread would queue data to the manager
process/thread. One reader, one writer, guaranteed sequence.
Lee
|
| 5455.3 | | LASSIE::GEMIGNANI | | Tue Apr 22 1997 12:36 | 14 |
| Actually, no, the two should get interleaved but not intermingled.
The application style that you are talking about is the classical Unix
approach to asynchronous I/O, and it is used extensively for such
applications as RLOGIN, where the reader can sit reading a socket and
writing to the terminal while the writer can sit reading a terminal and
writing to the socket. No major coding there.
As long as the writers write messages which are complete (a single $QIO
for a continuous, complete "record"), then each will write their
records in turn without garbling each other. Even if they are forced
to wait for buffering or network window management, the messages will
be processed in their entirety in the order in which they are queued
against the socket.
|