Re: Distributed Objects overkill?
Re: Distributed Objects overkill?
- Subject: Re: Distributed Objects overkill?
- From: Wade Tregaskis <email@hidden>
- Date: Sun, 2 Nov 2003 18:05:29 +1100
I'm writing a networked program which as a side function hash a chat
client. Would it be overkill to use distributed objects to implement
the chat capability? As opposed to say, lower level bsd sockets and
NSFileHandles (as in macdevcenter's RCE example). I'm new to
networking so I honestly don't know. Also, if I do use distributed
objects, in the chat and in general, is it better to use oneway and
bycopy messages send strings from server to client. For example, the
client sends a oneway message to the server asking for possibly an
image, then the server sends a oneway bycopy message with the image
data. Or would it simply be better for the client program to say
something like NSImage *theImage= [distantObject image];
You'll get people saying it's definitely overkill, particularly the
more Unixy types. They'll point you towards some socket()/select()
examples and protocols like FTP or SMTP. You'll also get people saying
it's not, that it's a useful way of abstracting away the irrelevant
details and getting on with the good stuff. In case it's not obvious,
I'm in the latter camp. :)
[You could work to a compromise, using one of the ObjC networking
classes (e.g. NetSocket). But then you'll still have to concern
yourself with the raw protocol, plus you'll have to do a bit of
serialization and so forth...]
The overhead of using Distributed Objects is not huge. I've done some
quantitative testing in past, and found that the round-trip delay
between two [G3] computers for a message with simple reply (e.g. an int
or BOOL) is at most 2ms. The vast majority of that is probably due to
transmission times and the like - if you use Distributed Objects
between threads the latency is almost immeasurable. I haven't done so
much with determining bandwidth, although what I have done suggests
you'll get at least 75% the efficiency of raw sockets. So for your
use, there's no problems in the technical area.
With regards to oneway messages... it depends a bit on how complex you
want your implementation to be, or alternatively how well
multi-threaded it will be. If you don't use oneway methods - i.e. you
just work with the objects as normal - you won't have to write
event-orientated code; you can do most things procedurally. That makes
things a lot easier in some regards, but the downside is that you then
have to worry about what happens if the reply is not prompt (e.g. the
server is busy, or dead), in which case you risk locking up your app.
Conversely, this is particular dangerous for the server, since one
client could die and lock the server up completely (until the default
timeout occurs, which is usually about 10 seconds).
So, if you want a more robust system, use oneway messaging where
appropriate.
Whether or not you use bycopy is largely case-specific. If you've got
a method like -(BOOL)login:(NSString*)account
password:(NSString*)password then you'd probably want both parameters
to be bycopy, since it's pretty obvious the server will need them every
time - you don't want to add another round trip of messaging by
requiring the server to request them specifically[1]. On the other
hand, in methods where you're one or more parameters which aren't
necessarily used, you probably shouldn't make them bycopy, especially
if those parameters may be quite big.[2]
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
[1] Also, there's a danger here if you only make the account bycopy,
since malicious clients can then determine if an account name is valid
or not by seeing if the server then requests the password parameter.
[2] I think NSData's are always sent bycopy, or at least that's the
impression I get from watching DO traffic. I don't know so much about
NSString's, but I think they too default to being bycopy anyway. There
may be some default size limit for auto-bycopy... I haven't seen it yet.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.