Conference azur::mcc

    
    Hello Wim,
    
    thanks for your note.  
    
    The 'sleep' time was added after it was discovered that events were not
    delivered if the link was disconnected immediately after sending the
    event.  Five seconds was found to be the average time needed to
    reasonably ensure delivery.   Attached is some correspondence in
    response to entry #3444 on this same subject.
    
    Re issue #4, the buffer deallocation is corrected in the next version -
    thanks!
    
    -s
    
    ======================================================================
    
From:	TOOK::JEAN_LEE     "Jean Lee, 226-5528, LKG2-2/U3"  5-OCT-1992 10:27:52.58
To:	S_KO
CC:	
Subj:	note 3444 that I replied...(anothe one is coming)

From:	TOOK::JEAN_LEE     "Jean Lee, 226-5528, LKG2-2/U3" 28-JUL-1992 10:42:05.51
To:	TPLAB::COLLEYE
CC:	JEAN_LEE
Subj:	note 3444 that you entered...

Hi Joe,

	The delivery service that the Collector API provides is something
like a UDP service, no guaranteed.  The sending API disconnects the link 
right after issuing "send" request WITHOUT waiting for confirmation from the 
sink.  It is designed to be "unconfirmed" delivery, which is normal for 
event delivery service.  Its handshaking and transaction look like this:

		    ( API )	 	( SINK )

		connect init	------->
		    		<------- accept	
					   |
		     |			   v
		     |			 listen
		     V			   |
					   v
		send data	-------> receive(read)
		     | 
		     | (wait a little)
		     v
		disconnect

	Just like you did in your experiment, I lost events if I didn't 
apply a waiting period before API disconnecting the link.  I couldn't find
any supporting theory for it.  But I have spent some time to observe
the link connectivity and sink activity during the delivery.  I
found that very often the "read from the wire" operation on the sink
side has not even finished (the QIOW has not returned) when the
link is disconnected.  But if I let the API wait for few seconds, the
transaction will be completed before the disconnect occurs.

	5 seconds may be debatable. I used it only after I played with different
times, days and distance of delivery.  I probably should make it a settable
logical so that users can control it.

	Hope this helps.  If you know a better thoery or solution (other
than confirmed delivery), please let me know.  Thank you.

	Nice to hear from you again.

	Jean

    
    
    

Hello,

I've done some additional experimenting in the collector area and was glad to
see the base note questions as they helped with my understanding. I have
additional questions but please excuse my non-programming background if what is
asked doesn't sound correct.

>5 seconds may be debatable. I used it only after I played with different
>times, days and distance of delivery.  I probably should make it a settable
>logical so that users can control it.

I think having it as a settable logical would be a big win for the customers
looking into using collector but need better performance. I also think that
creative users will quickly find ways to use the collector for other uses other
than first intended, and those uses will need better (much) performance. A good
example is a procedure just written which updates my current map given network
statistics of the past. I call it the UTILIZATION SPECTRUM ANALYZER (ya just
got to love naming your own gizmos) and it updates every line on our map with
an appropriate severity (color) for rising values of circuit utilization from
the past. I can now send events for multiple dates to each line over a given
time period, the result is a color graphics of utilization of different dates
with the highest (or last) severity being shown. All utilization figures can
then be analyzed while looking at the BIG PICTURE (makes for a good fireworks
show to :) ). I'd even like to demo this stuff but it takes a bit too long,
customers would eat this stuff up given its use as a pseudo modeler.

If I have 39 lines to be updated with three events each it can take up to 15
minutes to complete. Each event takes about 8 seconds and I now know where 5
of those seconds went. Only about a half second is coming from my front end
procedure. I'd like to pump these events into the map as quickly as possible 
so I have the following questions and/or ideas:

You have stated you did experimentation with various delays. What was your
highest delay needed for LOCALLY sent events (ie. how far down can the 5 second
value come down if all events are local?)?

Time is spent in the CONNECT/DISCONNECT sequence I'm sure. Is it, or will it,
be possible to use a single connect/disconnect sequence to send multiple 
events? If you reduce the connect/disconnect sequence you also reduce the wait
sequence.

If the SEND DATA comes into a buffer, why would a link disconnect cause a 
failure of event reception? I would think the drop-off and pick-up function
could be seperated from the link status.

kind regards,
brad...



    
    
    

     
    If you're using the EVC API on VMS.  You can eliminate the 'sleep' 
    all together by adding a SYS$CANCEL call before the SYS$DEASSIGN calls
    in the code.  With this change the only delay is the overhead of having
    to connect/disconnect for each event sent.
    
    Joe G.
    

    
    Thanks for suggestions.  It seems to be a doable solution.
    We will play with it before we decide what to do.
    
    We have considered using a logical to allow users to control how
    long the "sleep" should be.  The decision will be made by the
    engineer as soon as she returns from Interop.
    
    Your feedbacks are always appreciated.
    
    Jean
    

Hi,


>    Your feedbacks are always appreciated.


I go for the acknowledgement mechanism for the datacollector send event.
In this case you are sure the event is send to the management station,
and you don't need a sleep() now because after the acknowledgement the link
can be broken. So this will 'always' work independent of the speed of the
network you are using.


/-/	Henk.

Hi,

Thanks for the answering so far.

I've tested the solution mentioned by note *.3; using SYS$CANCEL.
It works not correctly with the Collection AM.

A test of sending more than 100 events (serial) gives the next results;

 1) the number of Collector Events are OK, but some are missing
    and therefore some double. 
 2) In the Collection AM log file, I see that before some event logs,
    connection setup/shutdown messages are missing.






Regards,
Wim 

    
    re: .6
    
    I believe you have uncovered a problem with the MCC_EVC_SINK process
    itself and not with the use of SYS$CANCEL.  From what you have seen
    it appears that the sink process which is capable of multiple network
    connections at once is posting its reads on the net mailboxes with the
    same buffer.  This would explain why the correct number of events are
    received but you are seeing duplicates.
    
    I'm not a DECmcc developer so I can't tell you for sure.  But if this
    is in fact the case it must be corrected.  Putting in some sort of
    time delay factor will not correct this problem and from my point of
    view isn't a viable solution anyways. In you have a environment where you
    have let's say 20 collector event sources being directed to one node,
    you can bet you're going to see the same thing since the 'time delay' is
    a non-factor in this case.
    
    Joe

This problem is well known, documented in previous notes, QAR'ed, 
and we think, fixed in version 1.3

    Same topic, different question:

	The message format between the mcc_evc_api and mcc_evc_sink
	limits the size of the text message to 255 bytes.  Is there a
	workaround for this?  Is the message format/size limit changed
	in 1.3? 

	Thanks,
	John

Llast I llooked, it was still 255 bytes of data for V1.3.

/doug

    how much do you need?