New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tcp server<->sclang communication is broken in 3.7 #1099

Closed
miguel-negrao opened this Issue May 6, 2014 · 11 comments

Comments

Projects
None yet
3 participants
@miguel-negrao
Copy link
Member

miguel-negrao commented May 6, 2014

s.options.protocol_(\tcp);
s.boot(false);

(
s.addr.connect;
s.startAliveThread( 0 );
s.doWhenBooted({ "Yo".postln; s.notify; s.initTree });
s.makeWindow
)

s.addr.isConnected // -> returns true

but I get

ERROR: server failed to start
For advice:
[http://supercollider.sf.net/wiki/index.php/ERROR:_server_failed_to_start]
ERROR: server failed to start
For advice:
[http://supercollider.sf.net/wiki/index.php/ERROR:_server_failed_to_start]

It's working fine in 3.6.6

@scztt

This comment has been minimized.

Copy link
Contributor

scztt commented Jun 22, 2014

So, it looks like both sclang and scsynth are opening ports correctly:

scsynth   17798            fsc    7u  IPv4 0x9ff04e55825cea39      0t0    TCP *:57110 (LISTEN)
scsynth   17798            fsc    8u  IPv4 0x9ff04e5592823a39      0t0    TCP localhost:57110->localhost:49615 (ESTABLISHED)
sclang    19274            fsc   14u  IPv4 0x9ff04e5589daa639      0t0    UDP *:57120
sclang    19274            fsc   18u  IPv4 0x9ff04e5597b97251      0t0    TCP localhost:49615->localhost:57110 (ESTABLISHED) 

...and I can (with fiddling) get packets to send between them via TCP. One thing I notice is, OSCFunc is explicitly using UDP connections:

if(recvPort.notNil and: {thisProcess.openUDPPort(recvPort).not}, {
        Error("Could not open UDP port"+recvPort).throw;
});

I see OSCFunc's scattered around in important places in Server.sc. Perhaps responses from the server that are being dealt with via OSCFunc's are simply not happening with tcp? You might try as an experiment rewriting the Server-related OSCFunc's to NOT have an explicit address (to avoid opening the UDP one as per above) - if that makes everything work, then the UDP OSCFunc issue is definitely the problem.

Does that mean NetAddr needs to have a notion of whether it's a UDP or TCP connection? Or it needs to open both?

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Jun 22, 2014

That shouldn't really affect it. Any message passed to Main::recvOSCmessage should be processed by OSCFunc. So if tcp messages go through that it should be okay I think.

@miguel-negrao

This comment has been minimized.

Copy link
Member

miguel-negrao commented Oct 22, 2014

Is there any hope of getting TCP working again, or is supercollider/sclang<->server going to be udp only henceforth ? udp silently drops packages, which for some use cases is just not acceptable...

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 22, 2014

A clue:

s.options.protocol_(\tcp);
s.boot(false);

OSCFunc.trace; // silence
s.addr.connect;
s.startAliveThread( 0 ); // now we get replies

OSC Message Received:
    time: 4242.677322834
    address: a NetAddr(127.0.0.1, 0)
    recvPort: 57110
    msg: [ /status.reply, 1, 0, 0, 1, 680, 0.082866385579109, 0.15257565677166, 44100, 44099.993433907 ]

OSC Message Received:
    time: 4243.38550683
    address: a NetAddr(127.0.0.1, 15900)
    recvPort: 57110
    msg: [ /status.reply, 1, 0, 0, 1, 680, 0.078828223049641, 0.15257565677166, 44100, 44099.995783637 ]

OSC Message Received:
    time: 4244.082120058
    address: a NetAddr(127.0.0.1, 16018)
    recvPort: 57110
    msg: [ /status.reply, 1, 0, 0, 1, 680, 0.08245438337326, 0.1579417437315, 44100, 44099.994643341 ]

OSC Message Received:
    time: 4244.778633985
    address: a NetAddr(127.0.0.1, 15900)
    recvPort: 57110
    msg: [ /status.reply, 1, 0, 0, 1, 680, 0.082988984882832, 0.1579417437315, 44100, 44099.994478954 ]

OSC Message Received:
    time: 4245.486902866
    address: a NetAddr(127.0.0.1, 15905)
    recvPort: 57110
    msg: [ /status.reply, 1, 0, 0, 1, 680, 0.080970697104931, 0.15378151834011, 44100, 44099.993485789 ]

Note that the sending ports are incorrect, and seem to change from time to time. So the problem is not that they're not connecting or sending messages, it's that the sending port is being incorrectly reported, and the OSCFunc thus doesn't match it. Also the receive port is 57110, which is the specified port passed to the server.

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 22, 2014

Okay, I think I've almost got it:

  • The TCP receiver was not setting the receiving port at all, hence the garbage ports.
  • ConvertReplyAddress was unnecessarily converting from network to host order. (boost::asio seems to always give ports in host order)

These changes make it work but I need to check if they don't muck up UDP or anything else.

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 22, 2014

Hmm, also was setting recv port incorrectly. I think I better take a closer look. There're a few things I don't understand. PR soon.

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 22, 2014

Okay, my change broke UDP, but it only worked because handleReceivedUDP converted to network order and ConvertReplyAddress converted it back.

ConvertReplyAddress is only used in ProcessOSCPacket, and localServerReplyFunc, which funnily enough is for the internal server. That already seems broken in 3.6.5., so I don't think I've done it any harm.

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 22, 2014

That already seems broken in 3.6.5., so I don't think I've done it any harm.

Actually it's not broken, then or after my change, it's just that the IDE server meter ignores it.

muellmusik added a commit that referenced this issue Oct 22, 2014

lang: Fix TCP bugs
This fixes Issue #1099. The problem was to do with the way in which incoming TCP messages were constructed before passing to the lang:

- The remote port info was not being set at all, and was then being converted from network to host order in ConvertReplyAddress. This was not needed as boost::asio::ip always gives ports in host order. UDP only worked because port was converted to network order and then back in ConvertReplyAddress, so that was removed as well.

- The received on port was being set to the remote port, so that was also corrected.
@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 22, 2014

PR up. boost::asio is a bit of a tangle, at least for my puny brain, so please do test vigourously.

On a related issue, the procedure to start a tcp server is undocumented, and seems pretty clumsy. @miguel-negrao if you're sure that's the correct procedure and order, could you streamline if possible and update the help?

@miguel-negrao

This comment has been minimized.

Copy link
Member

miguel-negrao commented Oct 23, 2014

Scott, thanks for looking at this. I tested your PR and seems to be working good here with tcp. I've also made a pull request (#1215) for automatic connection to the tcp server. It will take some time until the server is ready to be connected to, so my patch just keeps trying to connect up to a max amount of tries. The first couple of tries will fail (with an error message, "NetAddr-Connect failed with exception: connect: Ligação recusada"). I don't know how to suppress that message, I think it comes for the primitive, using 'try' doesn't seem to help. For my machine a retry max of 10 was enough, maybe it has to be higher, don't know.

This is really useful for my work, thanks !

@muellmusik

This comment has been minimized.

Copy link
Contributor

muellmusik commented Oct 25, 2014

PR merged, so closing.

@muellmusik muellmusik closed this Oct 25, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment