liblo-devel Mailing List for LibLO

Hi Mike, welcome to the list.. :)


On Wed, Apr 30, 2008 at 4:40 PM, Steve Harris
<S.W...@ec...> wrote:
> It's tricky because OSC clients are allowed to send paths with
>  wildcards, like:
>     /channel/*/volume 1.0
>  and you obviously can't deliver one wildcard into another.

I think one could perhaps argue that if two wildcards hit each other
there is always a match.  (Anything matches anything..)  However I
guess this is more complicated for non-* patterns, like letter ranges.


>  On 30 Apr 2008, at 21:20, Mike Wozniewski wrote:
>
>  > Hi,
>  >
>  > I'm wondering if it's possible to create a handler that will be called
>  > for a 'partial path' of a message?
>  >
>  > That is, when /foo/bar, or /foo/sheefa, or /foo/anything is received,
>  > one unique method is called. This could almost be thought of as a
>  > handler with wildcards, where you would declare it something like
>  > this:
>  >
>  > lo_server_thread_add_method(st, "/foo/*", NULL, foo_handler, NULL);

Maybe try the following patch, it's a pretty minimal change to the
LibLo sources, re-using the pattern matching code that's already
there.  As Steve mentions above, there are likely cases where this
doesn't give you the desired results.  For example, if you register a
handler /foo/b*, and send it a message /foo/[a-d]efg, theoretically it
should match but it won't work.

However, maybe this simple change will at least suit your purposes..


Steve


diff --git a/src/server.c b/src/server.c
index 079ea34..fb0fa9b 100644
--- a/src/server.c
+++ b/src/server.c
@@ -763,7 +763,8 @@ static void dispatch_method(lo_server s, const char *path,
     for (it = s->first; it; it = it->next) {
        /* If paths match or handler is wildcard */
        if (!it->path || !strcmp(path, it->path) ||
-           (pattern && lo_pattern_match(it->path, path))) {
+           (pattern && lo_pattern_match(it->path, path)) ||
+        (!pattern && lo_pattern_match(path, it->path))) {
            /* If types match or handler is wildcard */
            if (!it->typespec || !strcmp(types, it->typespec)) {
                /* Send wildcard path to generic handler, expanded path
@@ -957,9 +958,11 @@ lo_method lo_server_add_method(lo_server s, const
char *path,
     lo_method m = calloc(1, sizeof(struct _lo_method));
     lo_method it;

+/*
     if (path && strpbrk(path, " #*,?[]{}")) {
        return NULL;
     }
+*/

     if (path) {
        m->path = strdup(path);

It's tricky because OSC clients are allowed to send paths with  
wildcards, like:
    /channel/*/volume 1.0
and you obviously can't deliver one wildcard into another.

the only other option is that the receiving handler would have to deal  
with the wildcard on reception, which is more logic than should be in  
the handler in the ideal world.

If you can enumerate the paths, then you can register each path with  
the same handler, but obviously if your application doesn't know the  
paths in advance you have a problem.

You can also build generic handlers by giving NULL as the path, but  
that doesn't help too much either.

- Steve

On 30 Apr 2008, at 21:20, Mike Wozniewski wrote:

> Hi,
>
> I'm wondering if it's possible to create a handler that will be called
> for a 'partial path' of a message?
>
> That is, when /foo/bar, or /foo/sheefa, or /foo/anything is received,
> one unique method is called. This could almost be thought of as a
> handler with wildcards, where you would declare it something like  
> this:
>
> lo_server_thread_add_method(st, "/foo/*", NULL, foo_handler, NULL);
>
>
> I would love to have this feature, so that I can parse the rest of the
> path myself.
>
> I've tried some basic experiments, however, and the wildcard doesn't
> work. The path is always matched exactly as written :(
>
> I would be so happy if a hander for "/foo" would get called any time a
> message started with /foo ... ie, the following method would be called
> for all of the above-mentioned messages:
>
> lo_server_thread_add_method(st, "/foo", NULL, foo_handler, NULL);
>
>
> Is there a way to do this using liblo?
>
> Thanks in advance,
> Mike Wozniewski
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

I'm wondering if it's possible to create a handler that will be called 
for a 'partial path' of a message?

That is, when /foo/bar, or /foo/sheefa, or /foo/anything is received, 
one unique method is called. This could almost be thought of as a 
handler with wildcards, where you would declare it something like this:

lo_server_thread_add_method(st, "/foo/*", NULL, foo_handler, NULL);


I would love to have this feature, so that I can parse the rest of the 
path myself.

I've tried some basic experiments, however, and the wildcard doesn't 
work. The path is always matched exactly as written :(

I would be so happy if a hander for "/foo" would get called any time a 
message started with /foo ... ie, the following method would be called 
for all of the above-mentioned messages:

lo_server_thread_add_method(st, "/foo", NULL, foo_handler, NULL);


Is there a way to do this using liblo?

Thanks in advance,
Mike Wozniewski

Hi,

I finished preparing Chris Hixon's patch for the
lo_message_deserialise() function and input validation.
Also, I re-worked my previous patch for multicast support and made it
less intrusive.

These have now both been added to svn, so please check out the latest
trunk to test these features if you're interested!
testlo still needs work to thoroughly test validation.

cheers,
Steve

Hi,

On Fri, Apr 25, 2008 at 5:04 AM, Jozef Henzl <pop...@gm...> wrote:
> Hello,
>  i did some tests of the liblo, and i found out that program using it can be
>  DoS'ed easily. Just send a random data/lot of an osc messages via the UDP to
>  the server at high rate, and it crashes within 2 seconds.

Thanks for the bug report.
(Actually if you have time, would you put it on the bug tracker in
sourceforge?  http://sf.net/projects/liblo)

This sort of test should be added to the usual test suite, I'll see if
I can do it.
Do you have any code that could be used for testing?  I imagine that
generating a bunch of random-number UDP datagrams shouldn't be too
difficult.


Steve

Hello,
i did some tests of the liblo, and i found out that program using it can be 
DoS'ed easily. Just send a random data/lot of an osc messages via the UDP to 
the server at high rate, and it crashes within 2 seconds.

My configuration is x86_64 system, gcc 4.2.1, latest liblo 0.24.

there is a backtrace of crashing code. Test was done with a server_example.c 
from the liblo tarball, and with an application i am currently developing.

#0  lo_arg_host_endian (type=LO_FLOAT, data=0x90b4e420) at message.c:281
#1  0x00002ac1750b5261 in dispatch_method (s=0x603030,
    path=0x6bfa40 "<lot of random data>"..., data=<value optimized out>) at 
server.c:725
#2  0x00002ac1750b5a1d in lo_server_recv (s=0x603030) at server.c:609
#3  0x00002ac1750b5c95 in lo_server_recv_noblock (s=0x603030, timeout=10) at 
server.c:489
#4  0x00002ac1750b662d in thread_func (data=<value optimized out>) at 
server_thread.c:144
#5  0x00002ac1752eb020 in start_thread () from /lib64/libpthread.so.0
#6  0x00002ac1755c5f8d in clone () from /lib64/libc.so.6
#7  0x0000000000000000 in ?? ()

Thanks,
-- 
Jozef Henzl
http://popcorp.org
http://chan.cz

Hi,

I added the broadcast patch to SVN.
Also, I configured the patch tracker to email the liblo-devel list
when a patch is added or modified.
If this bothers anyone please let me know.


Steve

Hi,

I've finally got some time available to devote to liblo, so I thought
I'd just try to summarize several issues, some new and some inherited,
that I've been thinking about / working on, but haven't yet resolved.
Rather than reply to very old emails, I'll just list them here.
Perhaps some discussion will help to come to some conclusions.

* Apply proposed patch for level 2 broadcast support.

This patch uses strcmp() to check for the broadcast IP, which I'm not
convinced is the ideal way to do it.  However, it likely won't break
anything so I might apply it in the meantime until something better
can be devised.

* Is it valid to update the lo_client_socket structure when a new
server is created.

This one is purely internals.  There was some question previously that
when a new lo_server is created, the lo_client_socket is incorrectly
updated and so subsequent lo_send() calls do not send from the right
address.  The answer I think is that if the sender is important, the
function lo_send_from() should be used instead.  (Presuming there
exists a server to receive replies.)  However, it made me think about
lo_client_socket and whether it should contain only the first socket
created, or the latest.  It's unfortunately one of the only global
variables in the library, is it necessary?

* lo_message argument of handlers is invalid, messages cannot be re-sent.

This may be less than simple to fix, but it definitely breaks the
expected behaviour.  Perhaps at the very least it should be
documented.

* TCP support needs looking at.

TCP connections, afaik, are currently closed after a single message,
which isn't the most efficient use of the protocol.  Unfortunately I
think (correct me if I'm wrong) the standard for using OSC over TCP is
less formally defined than UDP.  It will be necessary to look at other
implementations to see how they handle it.

* Multicast

I submitted a patch for this a while ago, but haven't integrated it
into the project.  However I'll be needed the functionality soon for
another project, so I'll try to take a critical look at it again.

longer-term issues:
* ZeroConf (Avahi/Bonjour) support, patch is available for simple
announce, considering applying it, but what about further support for
namespace querying.
* Determine whether getnameinfo() should be used in IPv6.  (caused
slowness for IPv4, so needs testing..)
* There was some code previously proposed for a "deserialise" function
which would be useful, but it does not apply to the current trunk.
* I'd like to make the pthread dependency a configurable option.


Suggestions welcome!

Steve