Wise? Stupid? Somewhere in between? Thinkin' out loud...
Wise? Stupid? Somewhere in between? Thinkin' out loud...
- Subject: Wise? Stupid? Somewhere in between? Thinkin' out loud...
- From: Dakidd <email@hidden>
- Date: Thu, 1 Jul 2004 23:26:07 -0700
Bear with me as I "think out loud", wouldja? Thanks. :)
I've been tinkering with the concept of a dead-simple TCP/IP networking
library for use with OT, writing to target Carbon on 9.1, and using the
newest OT distribution I know about (The current one at
developer.apple.com).
Please, nobody say GUSI at me... I have my reasons for not wanting to use
it, and I'd prefer not to have to go over them for the fourteen bajillionth
(or so it seems) time.
When I say dead-simple, I mean *REALLY* *TRULY* dead-simple. Absolute bare
minimum to carry on a TCP/IP conversation with a server or client. The
entire function list consists of InitConnectLib(), ListenForConnect(),
ConnectTo(), SendTo(), ReadFrom(), DisconnectFrom(), and KillConnectLib().
At this point, I've been testing it with it set up to track a maximum of 32
connections, kept track of internally through an array of "ConnectionRef"
structs, each of which is (Hopefully... I may have to change the struct
again as more information comes into my reach or my coding strategy
changes) completely self-contained for any type of operation the library
does, and is intended to be considered opaque.
So far, so good.
I've got InitConnectLib(), ConnectTo(), SendTo(), DisconnectFrom(), and
KillConnectLib() operational. Before I start trying to get fancy with the
ListenForConnect() and ReadFrom() calls, I wanted to check on something
that may bear on how I end up coding them.
I've currently got a very generic notifier in place, and I'm calling the OT
functions I use asyncronously from the main thread. The notifier gets a
ConnectionRefPtr in the context variable, which I then use to stuff the
code, result, and cookie inputs to the notifier into the ConnectionRef, and
I set some flags, also held in the ConnectionRef. I look at the code value
as it goes by, and if I see an OTSyncIdle event, I YieldToAnyThread().
Otherwise, I simply fall out of the notifier.
Now, as I understand things, the notifier is (or should I say "the notifier
could be"?) running at interrupt time, which means that I can't really do a
whole lot due to the danger from memory being shifted around, and I want to
do the "exit, stage immediately, even!" thing as quick as possible, right?
That's where the yield I mentioned (as well as others scattered about the
code in logical-seeming places) comes in.
As part of InitConnectLib()'s operation, I start up a thread,
"MyServicingThread", which does nothing but loop until a global goes true,
at which point it politely digs itself a suitably sized hole, lays down in
it, and dies.
While it's running, it proceeds to loop through each ConnectionRef entry in
the array, asking "Is this Connection alive?" If so, it asks the connection
"Do you need an event serviced?" If the answer to that one is also yes, the
event gets serviced as it would have been in the notifier, with the benefit
that I'm now working at system task time, so anything I need to do is fair
game. Or have I missed (or misunderstood) something? Other than "What if
another event comes in before the current one is serviced?" - I intend to
do somthing about that. Later. Right now, I just want base functionality in
both directions, and as both the active and the passive peer.
I'm calling YieldToAnyThread() after each pass through the array.
What I'm figuring on doing with the read routine is grabbing whatever data
is available (as indicated by the event), cramming it into a buffer
(pointed to by an entry in the ConnectionRef struct - might end up using a
TNetbuf struct for it) and setting a "There's fresh data available" flag in
the ConnectionRef struct for the ReadFrom() function to look at when it
gets called.
Everything sound reasonable so far?
Am I overlooking anything critical, or have I managed to cover everything
I'm likely to need? I've been wondering, on and off, about some kind of
"GetStatus(ConnectionRef)" type function, but haven't come to a decision on
whether it'd be worth having.
Any thoughts from anybody. Sanity checks? Whatever?
Don Bruder - email@hidden <--- Preferred Email - unmunged
I will choose a path that's clear: I will choose Free Will! - N. Peart
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.