To: stik@ON-Luebeck.DE
Subject: Re: [11]  STIK: STIK/DIALER                                                      


On Sat, 24 Aug 1996 23:00:15 Peter Rottengatter <perot wrote: 
>
>On Sat, 24 Aug 1996, Ronald Andersson wrote:
>
>> I do not, however, see any need for any TOS-type or TTP-type clients, and today
>> no such clients exist AFAIK that have not been replaced by GEM applications.
>
>I remember a statement of Michael Guse I completely agreed with. He said 
>if some net tool only would write one line of text for output then it 
>would be overkill to make a GEM application out of it. Any modern desktop 
>can be operated with a command line interpreter running at the same time, 
>Gemini for instance even has it integrated.

Yes, but it really is another form of overkill to plop a cli window on top of
the screen just to diplay a text line that would fit in a simple alert box.
BTW, whatever has happened to Michael, it's been quite a while now, and no word.


>Often significant improvements to the clients require more output, or 
>more input, so a GEM interface is always a neat thing. But I'd never 
>dismiss a useful tool just because it is a .TOS program.

Neither would I, but nevertheless they will not be able to use any new features
of STiK that directly interact with the AES, since they are incapable of that.
And as I said, the old interface should remain, and they'll have to stick to it.


>> >Half a second is still not smooth enough. I guess the only way around 
>> >this is exchanging the polled ports by interupt driven ports. I've been 
>> >thinking about this. Possibly the whole thing could be done by modifying 
>> >the device-lib STiK uses for port traffic. That way Dan wouldn't need to 
>> >spend any time on this. It must be done by someone with solid assembler 
>> >experience. I could do it, but I'm short of time, and it would be hard to 
>> >do any more debugging on the Dialer ;-)
>> 
>> Well, I'm not well informed on the device lib, but with sufficient info
>> I should be able to do it too, but I suspect many STiK routines need to
>> be part of the actual interrupt routines and don't know if it's practical.
>
>The device-lib provides calls for receiving and transmitting bytes. I 
>wanted to modify it that way, that the send() call only writes it's data 
>to some buffer, so that it can return immediately, and some interupt 
>routine writes byte by byte to the port. That way the send() only has to 
>block if the amount of data exceeds the buffer size. Correspondingly for 
>receive(). I guess no changes are needed for other parts of STiK.

The way you describe it this would be necessary for a truly non-blocking version
since it is evident from the above that regardless of how they are polled, the
current routines do block during the actual transfer operations, which may be
a majority of the time since the modem speeds are a significant bottleneck.


>> It might be better to use a routine linked to the 200Hz system interrupt
>> instead, but that should of course be in speed-optimized assembler.
>
>True. I think the 200 Hz interupt needs not to be touched. I might be 
>wrong, though, but primarily the corresponding port interupts should be 
>used, that only fire if data traffic is upcoming or required.

For the actual reception of port data I agree, I was thinking more of having a
way for STiK to continuously move completed incoming packets into client data
structures, such as we have discussed previously.
It remains to be seen if and how such structures should be implemented of course.


>> I'm perfectly willing to take this on when we are certain that the CSLIP
>> routines are as functional as the SLIP ones. I have _no_ feedback on this yet,
>> except from myself and Dan, for whom they now appear to function well.
>> (I've stayed in CSLIP for several days now.)
>
>I could send you the device-lib, however, I would prefer if you'd ask Jan 
>Kriesten for it : kriesten@mailer.uni-marburg.de

Ok, I'll send him a letter then.


>> I agree completely, and since this requires a rewrite to get new interrupt
>> routines, we should take this opportunity to add the missing pieces for full
>> multi-client support.
>
>As noted above, I think this can be very well separated, so one could be 
>done without the other without any drawbacks.

Possibly, but I see no special benefit in delaying either, although this may be
unavoidable, since we must first reach agreement on what should be done.
(Not just us two that is, but all concerned, and especially Dan.)


>Should I know this language ?

Not necessarily, it just said: "Forty-two, Mister."
(and that you should recognize.)


>> >I can't see whether this affects the actual _interface_. However 
>> >limitations might arise from the implementation on STiKs side. I guess 
>> >it's this what you meant. Or do you wanna say there is a problem with the 
>> >interface itself ?
>> 
>> No, it's mainly such things as lacking interrupt structure and separate client
>> data structures that mars the current implementation.
>
>Lacking interupt structures are an entirely STiK internal matter,
>so it's got nothing to do with the interface.

Not directly, in terms of arguments needed etc, but it does affect the capability
and efficiency of the interface functions since these would be improved if the
client was not locked up even during actual transmission/reception of data.


>For client data structures you're sort of right,
>new calls are needed to tell STiK about them,
>but then again the existing calls need not to be changed, I guess.

Agreed.


>On the other hand, I'm still not convinced that we need those data 
>structures to be supplied by the client (see below). If this holds, the 
>whole interface doesn't need any change at all, not even added calls.
>
We do need some way to protect a connection from faults in the handling of other
connections (eg: crashed or locked up clients).


>Sure, it's just that any message here goes to every member of the list, 
>so none should feel personally talked to. Instead, if you feel it doesn't 
>fit you, consider it for someone else.

Yes, but it's a bit confusing that English no longer uses different pronouns
for singular and plural cases of 'second person', like our languages do.
English still does so for 'first' and 'third' person pronouns after all.


>> Agreed, though I think it's better to add new functions rather than changing
>> old ones to incompatible usages.  This way adaption to the new methods may be
>> done gradually rather than in one all encompassing step (harder to debug).
>> All multi-client functions needing new buffers will require new arguments.
>
>Don't think so. Already STiK uses a unique identification (handle) for 
>every open connection. If STiK considers each connection to be owned by 
>a separate process (even if that's not true) then the job is done. Now, 
>STiK could allocate a chunk of internal memory associated with that 
>particular connection to hold all non-global structures (local to that 
>connection, or, to that client). This should be done by the open call. 
>The close call could release the memory. This way no change for the 
>interface is needed, and still each process has it's own set of 
>structures. Some may have two or more, because they have two or more 
>connections open, but that won't hurt.

That should work yes, but a drawback is that the buffer will then always have to
be of a standard size, since STiK can't know what the client needs are.
For that to work, the standard size must be sufficient for the most demanding
clients, which may lead to a waste of memory.


>> That is quite correct, and was what I actually meant.  Clients must supply
>> separate flags and buffers for each separate connection to be used.
>
>See above, I think STiK should allocate them itself, not requiring the 
>client to do so. Two advantages : The interface isn't hurt, and if STiK 
>needs more local structures (more buffer size) the clients need not to get 
>recompiled.

These are the advantages, yes, but this way no client can ask for a buffer
adapted to his needs. (eg: CAB.OVL might need an extra-large buffer)


>Again I was unprecise. set_buffer() must set the buffer for a 
>_connection_. There are clients having two connections with lots of 
>traffic on one (requiring a large buffer) and little traffic on the 
>other (the normal buffer would do). An example is ftp.

Yep, and here we evidently agree that buffer size should be individual.
We could cater for both variants of course, letting the 'open' function allocate
a buffer of default size, which demanding clients could replace by one the have
allocated themselves, by calling 'set_buffer' before doing any I/O.


>> Please clarify.
>> A simple 'data_is_present' flag can not discriminate between connections.
>> Each connection should have a separate flag telling the client whether he has
>> data for that connection or not.
>
>I wasn't talking about a single flag. Of course it's got to be one per 
>connections. What I was talking about is that the interface already does 
>it the right way : CNbyte_count() returns the flag (basically) on a per 
>connection basis.

Yes, but if the flag actually exists in the clients data structure, it can be
tested without having to call the interface at all, although I begin to realize
that this does not fit how reception is made today.  This will require the type
of interrupt operation discussed further above, to be meaningful.


>> Correct!  Let me rephrase the above example then.
>> 
>> struct conn_blk *conn_list[ MAX_CONNS ];  /* keeps track of connections */
>> 
>> But even so, I find it higly suspect to allow  two clients to work through the
>> same connection, though I agree that this need not directly concern STiK.
>
>In case of files, be aware that STiK and the Dialer do precisely that ! 
>The Dialer uses the file "AUX:" in order to dial, then passes this file 
>to STiK.

Mmm, yes, and I thought of some other useful ways of doing it with actual
connections too, like having plug-ins for some clients etc.


>I guess the only thing we might still not agree is whether the 
>applications need to be required to provide space for STiK internal 
>structures that are non-global. I think they shouldn't, it's STiKs job.

I agree that STiK can assign default structures, but I see no way that STiK can
identify when a connection might need a larger buffer, so I still think it
better if the client can ask STiK to use a supplied buffer instead.
This could be done with a 'set_buffer' call, which would then be optional.


>> No longer !
>> Dan has confirmed your view of this !
>
>Getting confirmed makes me always happy ;-)

Unfortunately our discussion on the interrupt support makes it clear that it is
only between packets that the routines do not block.  During actual reception
or transmission they are still apparently locked in the STiK code, spending most
of the time waiting for data on the serial interface.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
