Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
- Subject: Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
- From: Dakidd <email@hidden>
- Date: Tue, 13 Jul 2004 23:19:10 -0700
>
Subject: Re: Wise? Stupid? Somewhere in between? Thinkin' out loud...
>
>
At 23:26 -0700 1/7/04, Dakidd wrote:
>
>Any thoughts from anybody. Sanity checks? Whatever?
>
>
It sounds like you're spending a lot of time worrying about
>
traditional Mac OS, which is a waste of time IMHO. Many of the
>
concepts you describe won't port nicely to Mac OS X (for example,
>
Open Transport, polling, cooperative threads), which means that the
>
code you write today will not be useful in the long term.
Understood. However, I have to code to what I've got, and what I'm likely
to have in the realistically forseeable future. Which means 9.1/classic/OT.
I wish I had the cash to throw at new hardware/OS/tools, but I don't, so
I'm making do with what I've got.
>
>
Perhaps if you could explain what your application does with network,
>
I could suggest some alternatives that would integrate well into
>
traditional Mac OS and Mac OS X.
This package/library/whatever is intended to be a "general purpose,
dead-simple" networking setup that takes the headache out of using OT for
TCP/IP networking.
I don't need or want to know about endpoints and ports and 800+ pages of OT
Docs. All I want or need is "ConnectTo()", "ReadFrom()", "SendTo()", and
"DisconnectFrom()" routines that talk across TCP/IP, and "just get the job
done" without having to cope with the insanely over-complicated train-wreck
we know as OT beyond being sure it's available on the system at run-time.
Basically, I guess I'm trying to "re-write Unix", but without rewriting
Unix, if you follow my drift - I want a reasonably painless interface to
networking capability that can be taken from OS to OS with nothing more
than a bit of glue to translate my "generic" ConnectTo(), ReadFrom(), etc.
call into the proper sequence of OS-specific calls, whatever that may
actually be. As of right now, I'm needing to write "OT-glue".
>
Anyway, enough preaching,
Thanks. I appreciate that. Nothing burns my cookies like being told "Do it
this way or drop dead."
>
let's answer some questions.
>
>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?
>
>
Basically true. While it is possible to run your entire networking
>
engine out of the notifier, it sounds like you want to run mostly
>
from a thread, in which case it makes for your notifier to do the
>
minimum amount of work and then split.
OK, good. Sounds like I'm on more or less the right track then. (But like
they say, "The devil is in the details"... So far, I'm not smelling
brimstone or seeing horns, bat wings, and a pointy tail...)
>
>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?
>
>
Sure. Except you haven't really told us anything about the behaviour
>
of ReadFrom if the connection doesn't have sufficient data to satisfy
>
the request. Do you expect ReadFrom to block, yielding to other
>
threads? Or does it just return the data that has arrived so far?
That concept is still up in the air. I've toyed with several ideas, none of
which seem to be quite right for all (or reasonably close to all)
situations, even though all of them address one problem or another that
each of the others miss.
Ideally, I want to call ReadFrom(ConnectionRef, Buffer, BufferLength) and
get back either a positive number indicating the number of bytes read into
the buffer, a zero (Nothing available, try again later) or an OSStatus to
signal an error. Blocking is to be avoided if at all possible - No data on
this connection? Go deal with something else until some arrives.
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.