sauoq

I need Max to talk with a service running on another machine. It speaks a proprietary protocol over both UDP and TCP. I have a library that constructs the packet payloads. They are stored in buffers of unsigned bytes; the message length varies from message to message but is always known.

My initial goal is to write a simple external (in C) that, upon receiving a bang on its sole inlet, will output the raw message data on its outlet packaged such that it can be sent via mxj net.udp.send.

So, I'm pretty new to Max and writing externals--I've written a couple very simple ones--and I'm not sure how I should be packaging my data for output from this external. Any advice would be greatly appreciated. Examples even more so.

I need Max to talk with a service running on another machine. It speaks a proprietary protocol over both UDP and TCP. I have a library that constructs the packet payloads. They are stored in buffers of unsigned bytes; the message length varies from message to message but is always known. 

My initial goal is to write a simple external (in C) that, upon receiving a bang on its sole inlet, will output the raw message data on its outlet packaged such that it can be sent via mxj net.udp.send. 

So, I'm pretty new to Max and writing externals--I've written a couple very simple ones--and I'm not sure how I should be packaging my data for output from this external. Any advice would be greatly appreciated. Examples even more so.


sending-raw-network-messages

it is slightly unclear to me whether you need help with sending the messages over the network, or with packaging your data according to the proprietary protocol. For the first case, I would recommend my set of raw networking objects within The sadam Library (

 which were exactly designed for these kind of things. For the second case, it would be hard to advise on how to pack your data without knowing more about the actual protocol...

it is slightly unclear to me whether you need help with sending the messages over the network, or with packaging your data according to the proprietary protocol. For the first case, I would recommend my set of raw networking objects within The sadam Library (http://www.sadam.hu/software), which were exactly designed for these kind of things. For the second case, it would be hard to advise on how to pack your data without knowing more about the actual protocol...

Thanks, Adam. Sorry I wasn't clear. I don't need help packaging the data according to the protocol. I have a library that does that nicely. The relevant function in that library returns a structure containing a pointer to the data and the length in bytes of the data buffer. What I'm struggling with is how to send that data via my external's outlet to be consumed by mxj net.udp.send.

I've seen your networking objects and considered using them. Other than the fact that they are not java, are they offering an advantage over the mxj net.* objects?

The reason I didn't choose to use yours right off the bat was that it appears you do not support multicast, which I will require before too long. I think I sent you mail via your website inquiring about that but, as far as I know, never received a response. Sorry if you sent one and it was routed to my spam folder or something.

Thanks, Adam. Sorry I wasn't clear. I don't need help packaging the data according to the protocol. I have a library that does that nicely. The relevant function in that library returns a structure containing a pointer to the data and the length in bytes of the data buffer. What I'm struggling with is how to send that data via my external's outlet to be consumed by mxj net.udp.send. 

I've seen your networking objects and considered using them. Other than the fact that they are not java, are they offering an advantage over the mxj net.* objects? 

The reason I didn't choose to use yours right off the bat was that it appears you do not support multicast, which I will require before too long. I think I sent you mail via your website inquiring about that but, as far as I know, never received a response. Sorry if you sent one and it was routed to my spam folder or something.


wow! As I've never received that mail, I just tested the form on my website, and it seems that it was broken! Apparently, I forgot to set up a recipient for the webform (I'm not very good with CMSs...) Now it's fixed. Sorry for the inconvenience.

The main advantage of my objects over the mxj ones is that you can't send binary data with the mxj stuff (at least, this was the case when I developed my externals, but a first test shows that this behaviour did not change as of Max 5.1.9). The mxj objects will interpret the incoming messages as 7-bit ASCII character strings; therefore, if you have a real binary stream (consisting of 8-bit bytes), the transmitted data will be corrupted. I'm not sure whether this truncation of data happens within the net.* objects or already at the Max->Java bridge; anyway, the point is that, unless you are absolutely sure that you are sending 7-bit data, you won't be able to use the Java-based solution. This was actually the main reason why I did those externals.

Unfortunately, my objects don't support multicasting, and although I've had some plans to create a multicaster, I've never had the time to do so and I've personally never needed it for my projects (nor I got any commission for them), so although it might happen in the far distant future, I would advise you against counting on a "sadam.multicast" object in the near future; if multicast is a must for you at this point, I'd seek for another solution.

Such a solution could be, for example, if you have access to the source code of the recipient of your data. In that case, you could rewrite the receiver software to accept 7-bit binary data, in which case you could easily adopt the mxj-based senders. However, if this was the case (ie. you can rewrite the receiver software), I would implement a base64 encoding on both sides, as there are many out-of-the-box solutions for that, both in Max and in C/C++/Java. Another solution might be to write your own multicaster external - depending on your programming skills, this could be either quite easy or quite hard to do.

I'm sorry for not being able to be more helpful. :-(

The main advantage of my objects over the mxj ones is that you can’t send binary data with the mxj stuff

Ouch. Yeah, that's not going to work for me. And changing code on the other side isn't an option either. I definitely need 8-bits and I definitely need multicast.

Sounds like my only option is writing it? Hard to believe there's not a generic full-featured solution for sending 8-bit binary data via UDP.

I've got plenty of experience with C and networking (on Unix, anyway.) Not so much with Max. That'd be my main hurdle.

If you are willing, maybe you can be still be helpful... If I were to do this, I'd be mostly reinventing the wheel anyway. So would you mind sharing your code? I'll look at extending it for multicast and give you whatever I come up with. If it suits you, you can roll it in or add it as another object in your sadam library.

Ouch. Yeah, that's not going to work for me. And changing code on the other side isn't an option either. I definitely need 8-bits and I definitely need multicast. 

Sounds like my only option is writing it? Hard to believe there's not a generic full-featured solution for sending 8-bit binary data via UDP. 

I've got plenty of experience with C and networking (on Unix, anyway.) Not so much with Max. That'd be my main hurdle. 

If you are willing, maybe you can be still be helpful... If I were to do this, I'd be mostly reinventing the wheel anyway. So would you mind sharing your code? I'll look at extending it for multicast and give you whatever I come up with. If it suits you, you can roll it in or add it as another object in your sadam library.


sorry I can't offer any help in this immediate discussion (i know little about networking), but I would be very interested in a multicast object if you guys are able to collaborate on such a project...

actually, I'm not sure whether there are no other options. It's hard to believe for me as well that such basic things are missing from Max, so perhaps it would be worth to ask a question on the general Max forum to make sure that there are no other options.

If it turns out that there's no other solution and you volunteer to extend my objects with multicasting possibilities (and then back-share the code with me), I'd be happy to share my code with you. However, as I don't want to make my library open source for several reasons, we'd need to contact each other through e-mail to succeed with this. If you're interested, please drop me a message to my e-mail address, which you'd find by taking the first letters of each line of the following text (to avoid spam-bots):

sum dolor sit
amet, consectetur adipiscing e
lit. Vivamus ac dui viv
erra, matti
s l
acus nec, faucibus urna. Nunc nunc lacus, iaculis u
t pellente
sque non, pl
acerat a magna. Nunc con
dimentum hendrerit molestie. Vestibulum 
a ultricies nisl, ac aliqua
m metus
. Curabitur p
haretra dapib
us suscipit.


Note that I use spam-hammer on my account, so it may happen that your first mail gets automatically rejected by spam-hammer. If that was the case, just send your mail again. Alternatively, you can try the webform on my website, which seems to be fixed now.

P.S. I've just asked on the Max forum for alternatives: 

https://cycling74.com/forums/raw-binary-network-messages-and-max

P.S. I've just asked on the Max forum for alternatives: https://cycling74.com/forums/raw-binary-network-messages-and-max .


Thanks, Adam. I've sent you email. Let me know if you don't get it and I'll resend.

Sending raw network messages