| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 848.1 | NOPE! we won't handle that | TOOK::CALLANDER | | Wed Mar 27 1991 19:00 | 13 |
|
Page 508 of the second volume of the 1.1 SRM states that ...
"is must always be present, even if no response data is to be returned."
To return a CVR of MCC_S_RESPONSE you must have the response code in the
out_p parameter. This simply means you have to do a put param begin with
the response code followed by a put param end. The same is also true for
an exception. The only time you can return an out_p with no contents in
it is when the call routine returns a call failure (NOT to be confused with
an exception).
Hope this helps.
|
| 848.2 | No such thing as a null response | TOOK::STRUTT | Colin Strutt | Wed Mar 27 1991 23:32 | 8 |
| re: .0
This problem is the same as other management protocols (such as NICE)
encounter. You should *not* return an "empty" reply, despite what .1
says. You should arrange to have your AM buffer one protocol message ahead,
and when the 'next' message says you're done, return the reply for the
current message with the handle re-initialised.
Colin
|
| 848.3 | Can two different answers both be right? | TOOK::GUERTIN | I do this for a living -- really | Thu Mar 28 1991 11:43 | 11 |
| re:.0
Their both right, but Colin is more right (righter?). In YOUR case,
you should implement a look-ahead algorithm just as Colin described.
If there is just one response (handle is NOT set to more) and there are
no attributes to return (for example, a characteristics partition where
the Entity has none of the possible attributes currently defined), then
you should return a response with no data (just as Jill described). Am
I confusing things more?
-Matt.
|
| 848.4 | This bring up other problems... | ULTMAT::BELANGER | A ROSE by anyother name, would not be manageable | Thu Mar 28 1991 14:35 | 16 |
|
re:.3 and .4
The problem with this approach is that some of the requests that may be
sent may never indicate that the last reply has been received. If we
have to buffer the next reply before being able to return the current
one, the last reply we received may not be returned to the caller until
either the thread has been signaled to cancel or a timeout has occurred
(which can and probably will be on the order of minutes). It would be
nice if a response can be given to the caller that the last reply was
really the last reply (ie: I lied when I said I had more). Also note,
this is the way OSI does liked replies. The last message contains no
information within it. It simply indicates that no more replies are
coming.
~Jon.
|
| 848.5 | | TOOK::STRUTT | Colin Strutt | Tue Apr 09 1991 21:22 | 21 |
| re.4
Jon,
if you have a well behaved protocol that is not subject to unecessary
delays, then you should follow the existing model in MCC, ie. always
return data, buffering ahead as necessary. That some protocols work
one way (by giving you a "there's no more" indication on the last
reply) and others work just the opposite way (by giving you the last
reply saying "there was no more") is just a fact of life that the
access module has to deal with, in order to provide a common API
(mcc_call_access) to the FMs. The API adheres to the entity model,
which says that all replies to a directive must be responses or
exceptions (or else an error in the call can be signalled).
Now if you have a badly behaved protocol, whereby the receipt of the
message that says "there was no more :-}" could be arbitrarily delayed,
then you have no choice but to add an additional (empty) response, or
perhaps even an exception to match the time-out condition. Note that
this will necessarily look ugly to the user. Hence the former approach,
mentioned in the last paragraph, is the preferred one.
Colin
|