Netreceive: EOF on socket #...
Hello everyone,
This is my first post on here, I've tried searching for a solution to my problem to no avail... Hopefully I'm not the only one who has come across this!
My patch is a very simple test of communication between java and max- I'm using the following code in my bang() method (in mxj):
TcpSender test = new TcpSender("localhost", 3000);
Atom a[] = new Atom[]{Atom.newAtom("Hello!"), Atom.newAtom(";")};
tic.send(a);
tic.close();
Now, in my patch there is only a netreceive object set to port 3000. When I send a bang into my mxj object I get the following in the Max window:
print: Hello!
netreceive: EOF on socket 132
I thought I'd cracked the problem by adding the ";" into the Atom in the code above, as previously the message wasn't coming through - I only got the EOF error... so, now I have the message and the error and I'm confused.
It's not a problem for this particular patch, but I'm testing for a patch that uses 100 or so netreceives at a time and the errors are crashing my mac!
Is it possible that it's a problem with the netreceive object itself? Or is there a far simpler way of doing this? Or am I missing something f-ing obvious?!
Thanks a lot, any help is much appreciated!
-s.
The EOF is indicating that the TCP connection has closed. Likely what
you want to do is create a TcpSender when your mxj object is created,
and close it when your object is deleted, and just create and send
atoms in your bang message handler.
If you don't need that kind of connection to persist throughout the
life of your object, you could also consider using UDP which is a
connectionless protocol.
r.
On 07-05-31, at 1312, Sam Salem wrote:
>
> Hello everyone,
>
> This is my first post on here, I've tried searching for a solution
> to my problem to no avail... Hopefully I'm not the only one who has
> come across this!
>
> My patch is a very simple test of communication between java and
> max- I'm using the following code in my bang() method (in mxj):
>
> TcpSender test = new TcpSender("localhost", 3000);
> Atom a[] = new Atom[]{Atom.newAtom("Hello!"), Atom.newAtom(";")};
> tic.send(a);
> tic.close();
>
> Now, in my patch there is only a netreceive object set to port
> 3000. When I send a bang into my mxj object I get the following in
> the Max window:
>
> print: Hello!
> netreceive: EOF on socket 132
>
> I thought I'd cracked the problem by adding the ";" into the Atom
> in the code above, as previously the message wasn't coming through
> - I only got the EOF error... so, now I have the message and the
> error and I'm confused.
>
> It's not a problem for this particular patch, but I'm testing for a
> patch that uses 100 or so netreceives at a time and the errors are
> crashing my mac!
>
> Is it possible that it's a problem with the netreceive object
> itself? Or is there a far simpler way of doing this? Or am I
> missing something f-ing obvious?!
>
> Thanks a lot, any help is much appreciated!
>
> -s.
Hello there,
Thanks for the speedy response! I think you may be right, however I'm still getting the same EOF message when I place the TcpSender constructor within the constructor of my class, or even when it's placed at the beginning of my class and declared public (I've also removed the .close() method).
I've tried replacing the TcpSender constructor with the UdpSender constructor and nothing at all happens when I bang my mxj object (I've added the second "1" argument to my netreceive object). If Udp is connectionless it may serve my purpose better as it sounds like it will require less maintenance, but at the moment it's not doing a great deal.
Hmm, time for a restart I think!
Thanks,
s.
On 07-05-31, at 1350, Sam Salem wrote:
>
> Hello there,
>
> Thanks for the speedy response! I think you may be right, however
> I'm still getting the same EOF message when I place the TcpSender
> constructor within the constructor of my class, or even when it's
> placed at the beginning of my class and declared public (I've also
> removed the .close() method).
>
Its been a while since I've looked at networking or java, but I think
what you need to do is have a TcpSender as a private member variable
of your mxj class, and create it in your constructor.
> I've tried replacing the TcpSender constructor with the UdpSender
> constructor and nothing at all happens when I bang my mxj object
> (I've added the second "1" argument to my netreceive object). If
> Udp is connectionless it may serve my purpose better as it sounds
> like it will require less maintenance, but at the moment it's not
> doing a great deal.
>
You will need to use a UDP receiver with the UDP sender.
Do the net.tcp.send/recv and net.udp.send/recv pairs not work for
your application? I don't know what your netreceive object is.
You might also want to try reading Beej's guide to network
programming if you have time, it will give you a better understanding
(maybe) of what's going on here. Its targetted at C programmers, but
you might be able to pick enough out of it to get going with java.
http://beej.us/guide/bgnet/
Good luck.
r.
Thanks for the help and advice - I am new to the networking and have a bit of perceptual block when it comes to Java!
The reason why I'm not using net.tcp.send et al is that I'm trying to use TCP/UDP to communicate between the Java program and a set of Jitter abstractions. The abstractions are dynamically created/killed by the Java program, which updates each abstraction during its lifetime (or at least hopefully will at some point).
Netreceive is a max external for networking written by Olaf Matthes- it's available from: http://www.akustische-kunst.org/maxmsp/
Anyway, thanks a lot!
s.
Max also has objects for UDP that are used to communicate with the
lemur.
udpsend and udpreceive I believe.
t
On May 31, 2007, at 14:20 PM, Sam Salem wrote:
>
> Thanks for the help and advice - I am new to the networking and
> have a bit of perceptual block when it comes to Java!
>
> The reason why I'm not using net.tcp.send et al is that I'm trying
> to use TCP/UDP to communicate between the Java program and a set of
> Jitter abstractions. The abstractions are dynamically created/
> killed by the Java program, which updates each abstraction during
> its lifetime (or at least hopefully will at some point).
>
> Netreceive is a max external for networking written by Olaf
> Matthes- it's available from: http://www.akustische-kunst.org/maxmsp/
>
> Anyway, thanks a lot!
>
> s.
Ah, thanks a lot for that! The UdpSender() worked instantly with the udpreceive object - problem is it doesn't understand the message being sent, so time to look up a Java implementation of OSC...
...some considerable time later...
So, I've looked at the com.illposed.osc Java implementation of OSC and needless to say, I can't even get the example to compile - we end up with a lot of compilation errors pointing to UnknownHostExceptions - to be honest I had hoped to not have to deal with java.net.*;!
Current state of progress:
My patch consists of a udpreceive connected to an opensoundcontrol object connected to a print. My bang() method is still:
-----------------
UdpSender test = new UdpSender();
test.setAddress("localhost");
test.setPort(5000);
Atom a[] = new Atom[]{Atom.netAtom("I am tired"), Atom.newAtom("Please work!")};
String s = Atom.toOneString(a);
post(a);
test.send(a);
----------------
Which is giving me:
I am tired Please work!
net.recv.udp: OSC packet size (19) not a multiple of 4 bytes: dropping
As far as I can tell, it seems that the message being sent needs to be converted to the OSC message format, so I tried using the following method from the Java OSC implementation:
----------------
OSCJavaToByteArrayConverter Henry = new OSCJavaToByteArrayConverter();
Henry.write("I am very tired");
Henry.write("Please work!");
Henry.appendNullCharToAlignStream();
//then to convert Henry's protected byte stream to a byte array
byte[] tester = Harry.toByteArray();
Atom a[] = Atom.newAtom(tester);
test.send(a);
----------------
Which gives me the following error:
104 97 104 97 104 97 0 0 112 108 101 97 115 101 32 119 111 114 107 33 0 0 0 0 0 0 0 0
net.recv.udp: OSC packet size (85) not a multiple of 4 bytes: dropping
Any ideas?! I think it may be the conversion from byte[] to atom[], altho it could also be the conversion from byte stream to byte[] as I have no reason to believe that the java osc implementation works.
Ack...
Ok, I switched over to the de.sciss.net library and it seemed to work fairly instantly (http://www.sciss.de/netutil/) - it's a little more low level than I would've liked, but I'm not complaining :)
I don't under stand why tour bang method wouldn't outlet a max message
which could be sent to udpsend.I also don't understand the need for an
osc object.udpsend and receive understand a large subset of osc but it
just seems like you are sending around max messages.maybe I am not
understanding something.