Re: [Javaosc-development] JOE

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

Hi guys,

I have been really busy with my day job these few days to look into javaosc.
However, I managed to do some brain-storming and some snooping around. While
thinking about address-space models, with respect to our discussion earlier,
I was thinking of various models we could use to speed up parsing.

Hashing is indeed a better method with a flat address space, and more
importantly for incoming messages without any wildcards. However, it seems
pretty difficult to parse wildcards using hash tables. One way we could
explore that is to define our own hashing scheme which supports wildcards.
However I cannot think of an easy way to do this. Do you have any ideas
reagrding this?

The other approach would be to maintain a parse tree as well as a
hash-table. Messages without wildcards can be parsed through the hash-table
and those with wildcards will have to be parsed through the tree. What do
you think?

As for the auto-conf, I am looking into it. Although, it is a great tool for
auto discovery of clients on network, I am not sure how much we can use it
for discovering other OSC clients on the network. I have never used it
before, so I am also not very sure myself.

Another thing that might enhance auto-config and auto-discovery of nodes is
OSC Queries. Do you have any idea what the official status is on this. And
more importantly, is it the accpeted query method in the community? I don't
have much contact with the OSC community, so I was hoping you guys could
give some suggestions.

Finally, I have a few questions about the version control in sourceforge.
How does it work? If I have some new changes that I would like to add in.
Like say a new data-type OSC-Blob. Should I check-in the changes into the
main trunk? Or do I create branches for such changes? Or do I just keep a
personal copy for now?

I have a couple of quick updates to add, OSC-Blob, and support for incoming
socket-address information to be passed to the dispatcher, and thus to the
service thread, so that it itself can reply to the message if needed. Of
course this will have to be replaced by a generic reply address when we
abstract off the communication mechanisms from the javaosc clients
themselves.

Thats all for now.

Thanks,

-Chinmay


On 9/14/06, Chinmay Pendharkar < ch...@gm...> wrote:
>
> 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
> >
>
>