Re: [Javaosc-development] JOE

[Chinmay P. <ch...@gm...>]

Hey,

I did get your earlier mail. But, I guess it's my turn to get really busy.
Anyway, here are some point..

I agree that the 3-thread model is not the best. What we were trying to do
was to extend JavaOSC with doing much code change to it. So it has ended up
being very awkward architecture. The reason for the two-thread 'server' was
that we were afraid that paring a long address in a huge tree based
multi-level namespace would consume too much time. And if the OS level
buffers for UDP packets are not big enough to hold that many packets at
once, there will be packet loss. The 2 server model avoids that by
retrieving all the packets and storing them in Java's address space. Of
course once can always overflow the JVM heap, if enough packets are being
sent. The tests done did indicate some packet loss at very high speeds of
packet transmission.

The third thread was just to support the time-stamp feature in OSC. We
thought it would be a better idea to let the server handle it than the user.
The decision was of course affected by our synthesis system's architecture.

The tree based address-space model was used for ease of interfacing with the
synthesis software that we were using. It seemed to be the most intuitive
and 'cheap' structure. Of course, for a more linear address space, hash
tables would be better data-structures. But, we realized that supporting
wild-cards tends to be difficult when using hash-tables. So if we can figure
out a method to support wild-cards over a hash-table, it would be great
idea. I can think of custom hash functions, off the top of my head. Any
other ideas?

I am not at all experience with sourceforge development. This is my first
time. So, I am sorry, if I end up doing something wrong. I have managed to
setup subversion access to the source tree. I will try to add my updates to
the tree over this weekend.

-Chinmay




On 9/14/06, Chandrasekhar Ramakrishnan <cra...@ac...> wrote:
>
>
> I'm having some problems with my mail server, so here's a second
> try...
>
> - sekhar
>
> ------- Forwarded Message
>
> To: jav...@li...
> Subject: JOE
> From: Chandrasekhar Ramakrishnan <cra...@ac...>
> In-Reply-To: Message from "Chinmay Pendharkar" <ch...@gm...>
>    of "Tue, 12 Sep 2006 07:34:23 +0800." <
> d32...@ma...>
> Date: Tue, 12 Sep 2006 13:09:59 -0700
> Sender: ci...@so...
>
> "Chinmay Pendharkar" schrieb:
> > Do take a look through the paper, and see if it would be useful to bring
> in
> > some of those features into javaOSC.
>
> I definately think so! In particular, the code to manage running the
> server in a seperate thread, support for the additional data-types,
> and the changes to the the parsing and dispatching (using a trie to
> store the address space), and the priority queue would all be great to
> incorporate.
>
> A few questions about JOE. First, is there a reason you are using 3
> threads in the multithread version?
>
> I would have probably implemented it differently To me, it seems more
> intuitive to use 2 threads. I would have used a multiple-writer,
> single-reader FIFO for communication between other threads and the one
> the server runs in. The server thread would be responsible for sending
> data into the socket and reading data from the socket. It would also
> parse the messages and put them into a priority queue. It would the be
> responsibility of the user of the library, then, to get items out of
> the priority queue and have them dispatched. The user could then do
> the dispatching in whatever thread is appropriate instead of having
> the server spawn its own thread for dispatching.
>
> The other comment is that maybe the namespace storage model should be
> made pluggable. Using a trie is great for programs that use a
> multi-level namespace, but some programs would rather use a flat
> namespace (e.g., SuperCollider). In this case, a hash-based
> implementation would be better.
>
> > Also, please tell me how I should upload the source of this JOE, or
> > if I should send it over email.
>
> The best way would be if you could make your changes in the source
> tree itself and make any existing JUnit tests pass and write any new
> ones that are necessary. You should have Subversion access to the
> source tree already. Let me know if you have any difficulty checking
> out or modifying the source.
>
> - - sekhar
>
> - --
> C. Ramakrishnan        cra...@ac...
> Illposed Software    http://www.illposed.com
>
> ------- End of Forwarded Message
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Javaosc-development mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javaosc-development
>