gardner@shl.com (Gardner Buchanan) (03/21/91)
CCITT X.219/X.229 Geniuses, I have a dumb question about using ROSE: I appologise in advance if it seems that I don't understand this enough to even ask a meaningful question but here goes... I find myself working with a presentation protocol which contains mostly Class 3, 4 and 5 operations. It looks like I will have a bit of trouble keeping track of all of the un-responded Invoke-IDs which will proliferate, particularly with the Class 3 operations. I'm not worried about deciding when I can re-use Invoke-ID values, since it is quite easy to never (within reason) reuse them at all, but I still might have to keep a table of invokes I've generated for a fair piece of history just on the off chance that an ERROR might be returned by the responder. So, does anyone know where in the CCITT/ISO docs it might say just how much history I might have to remember? X.219 Sec. 10.1.1.4 says that I may re-use Invoke-IDs after "a reasonably long period of time". This would, I guess, also apply to the length of time I must remember about the invokation. Does that seem right? Before asking the remaining questions, I will state that I DID NOT DESIGN THE APPLICATION OR ITS OPERATIONS!!!! Is it in general a good idea to use Class 3 and 4 operations if they lead to this difficulty in deciding when the operation is over? Do many other applications use them? Are there well known algorithms for maintaining a table of Invoke-IDs like the one I think I need? Is there something in the ISODE which I should look at? Thanks for any and all assistance, -- Gardner Buchanan gardner@shl.com Systemhouse, Ottawa (613) 236-6604 x375
kmont@hpindda.cup.hp.com (Kevin Montgomery) (03/28/91)
/ hpindda:comp.protocols.iso / gardner@shl.com (Gardner Buchanan) / 11:52 am Mar 20, 1991 / > I find myself working with a presentation protocol which contains > mostly Class 3, 4 and 5 operations. It looks like I will have a bit yick. > I'm not worried about deciding when I can re-use Invoke-ID values, > since it is quite easy to never (within reason) reuse them at all, but > I still might have to keep a table of invokes I've generated for a fair > piece of history just on the off chance that an ERROR might be > returned by the responder. yup- a simple way to do this is to have a ROSE function that returns the next invoke_id to use to the application. Then, ROSE can keep incrementing the value on each call, and thereby you can know the periodicity of the invoke_ids. Don't forget to have the numbers "roll over" the top. > So, does anyone know where in the CCITT/ISO docs it might say just how > much history I might have to remember? X.219 Sec. 10.1.1.4 says that I > may re-use Invoke-IDs after "a reasonably long period of time". This > would, I guess, also apply to the length of time I must remember about > the invokation. Does that seem right? I couldn't find anything when I'd implemented either. In some functional testing for an old implementation of ROSE I "rolled over" after 5 days of pretty intense testing. As I recall, invoke_id was defined as a short, which should encompass the possible invoke_id values if they're in the spec (someone has my copy + it's been a while). If it's defined to be 0-65535, then that's the upper bound on the number you can save. I don't recall any lower bound. How many you save really depends on the application- if you're planning on getting a response (result/error) for most operations, then you don't need to keep the queue of outstanding operations very large. As for design, I think I pushed each new operation onto the front of a doubly-linked list (we had the max possible outstanding operations case) and, when getting a response, checked through the list front->back to find the status information. This gave nice recency effects of quick response for newer operations. But then you have the problem of dealing with cleaning things out of the list when you roll over and start re-using values. For this I had a tail pointer and would check backwards to kill the old info for the invoke_id I was about to give away. This backward-killing process only had to occur after invoke_id rollover (=more efficient for the first 65535 operations) and, since the numbers pushed where monotonically increasing, the list ended up staying in order from highest (front) to lowest (back). A nice hack I didn't have time to do would be to change the list to be a list composed of arrays of 100 elements of status information. This would make looking things up a little faster, since you can access the first 100 and last 100 more quickly. But come on. In normal operation, they wouldn't probably roll over for a month of pretty intense use in a normal application (even X.500), and then incur a very little penalty on every operation. Not too bad as it was/is. > Is it in general a good idea to use Class 3 and 4 operations if they > lead to this difficulty in deciding when the operation is over? Do > many other applications use them? it's -really- nice to use class 2 (always a response) and class 5 (never a response). You can blow off the whole problem of saving state info of already invoked operations. We used 2 for normal operations for OSI applications and 5 as a hook for trace/log data (hey, if it ain't logged, who cares?). > like the one I think I need? Is there something in the ISODE which > I should look at? sorry, been a *long* time since I've taken a look at ISODE ROSE, so I have no clue remaining... kevin HP OSI old ROSE fart ps: this is the ROSE from our old X.500 implementation in our MAP product.