search

benbjohnson / melomel

External ActionScript Interface.
https://github.com/benbjohnson/melomel/wiki
Other
42 stars 8 forks source link

Issue Running the cuke-spark example #23

Closed nicolassenechal closed 13 years ago

nicolassenechal commented 13 years ago

Hi,

I am having problem running the cuke-spark example. Compiling and starting the server are fine. Chrome opens as expected and I can see the demo application. However, the testing does not pass the first Scenario declaration: Feature: Addition Scenario: Adding one plus two should equal three # features\addition.feature:2

Any idea what could be wrong? I am using Win7 with Ruby 1.8.7.

Cheers,

Nic

benbjohnson commented 13 years ago

Does the command line just hang or are there any errors shown?

nicolassenechal commented 13 years ago

No, just hanging.

Nek commented 13 years ago

As far as I remember there is a problem with no 'fork' available on pure windows. Melomel should work well on cygwin.

benbjohnson commented 13 years ago

Nic-

I looked into this for about two hours but I haven't figured it out yet. I know I've gotten Melomel to work on Windows XP before. I haven't tried it since upgrading to Win7. There's some kind of issue when sending the Flash socket policy file but I haven't nailed down what that is yet.

Ben

nicolassenechal commented 13 years ago

Nek,

Same issue on Cygwin unfortunately.

Ben,

Thanks for looking into this.

Nic

simongregory commented 13 years ago

We got round a similar forking issue running on XP using this https://gist.github.com/901675 it wasn't a particularly easy find but glad we got there in the end. BTW this is running on jruby, there were 'other problems' under alternatives.

benbjohnson commented 13 years ago

Thanks for the Windows XP integration code, Simon. The forking is one issue but there's something separate that seems to be specific to Win7. I've tried several times to figure out the connection issue and I can't seem to figure it out. Last time I looked I was able to get Melomel to connect sporadically. I've tried using a packet sniffer but couldn't figure out the problem. And I've contacted several people Adobe but I haven't had any response.

If anyone is good network/packet stuff for Windows, let me know. I could use a hand with this issue.

I haven't tried JRuby on Windows 7 yet. I'll give that a try.

GogKurt commented 13 years ago

I think we're having a similar issue. Is the app window just hanging as well?

I've tried this on Ubuntu and JRuby on XP with different versions of flash but still end up with the same result. (echos the first senario line and waits) I've checked tcpdump and can see traffic between the client and server ports so they are talking to each other. We're currently looking at the policy file as the xml is being sent to the flash object but we're not seeing a response coming back so end up stuck waiting.

Have you managed to get any further?

benbjohnson commented 13 years ago

GogKurt-

Can you send me the tcpdump traffic? There should be a policy xml request first and then a <connect/> string sent. After that, everything should be ready to go.

Ben

GogKurt commented 13 years ago

Wasn't sure about posting the output here but the preview looks ok. Let me know if you want it sent another way.

Yep, we've been looking for the to return something but it hasn't yet. :( Let me know if you need more info, I'm not sure how helpful the dump below will be

11:31:38.199367 IP6 localhost.10101 > localhost.36924: Flags [R.], seq 0, ack 3902922946, win 0, length 0 11:31:38.199515 IP localhost.38674 > localhost.10101: Flags [S], seq 176260955, win 32792, options [mss 16396,sackOK,TS val 21813790 ecr 0,nop,wscale 6], length 0 11:31:38.199530 IP localhost.10101 > localhost.38674: Flags [S.], seq 178076302, ack 176260956, win 32768, options [mss 16396,sackOK,TS val 21813790 ecr 21813790,nop,wscale 6], length 0 11:31:38.199548 IP localhost.38674 > localhost.10101: Flags [.], ack 1, win 513, options [nop,nop,TS val 21813790 ecr 21813790], length 0 11:31:38.208418 IP localhost.38674 > localhost.10101: Flags [P.], seq 1:24, ack 1, win 513, options [nop,nop,TS val 21813792 ecr 21813790], length 23 11:31:38.208461 IP localhost.10101 > localhost.38674: Flags [.], ack 24, win 512, options [nop,nop,TS val 21813792 ecr 21813792], length 0 11:31:38.208565 IP localhost.10101 > localhost.38674: Flags [P.], seq 1:219, ack 24, win 512, options [nop,nop,TS val 21813792 ecr 21813792], length 218 11:31:38.208575 IP localhost.38674 > localhost.10101: Flags [.], ack 219, win 530, options [nop,nop,TS val 21813792 ecr 21813792], length 0 11:31:38.208601 IP localhost.10101 > localhost.38674: Flags [F.], seq 219, ack 24, win 512, options [nop,nop,TS val 21813792 ecr 21813792], length 0 11:31:38.217889 IP localhost.38674 > localhost.10101: Flags [F.], seq 24, ack 220, win 530, options [nop,nop,TS val 21813795 ecr 21813792], length 0 11:31:38.217921 IP localhost.10101 > localhost.38674: Flags [.], ack 25, win 512, options [nop,nop,TS val 21813795 ecr 21813795], length 0 11:31:48.401570 IP localhost.48302 > localhost.843: Flags [S], seq 340320129, win 32792, options [mss 16396,sackOK,TS val 21816340 ecr 0,nop,wscale 6], length 0 11:31:48.401588 IP localhost.843 > localhost.48302: Flags [R.], seq 0, ack 340320130, win 0, length 0 11:31:58.640873 IP localhost.48306 > localhost.843: Flags [S], seq 498234255, win 32792, options [mss 16396,sackOK,TS val 21818900 ecr 0,nop,wscale 6], length 0 11:31:58.640892 IP localhost.843 > localhost.48306: Flags [R.], seq 0, ack 498234256, win 0, length 0

GogKurt commented 13 years ago

We've added a few debug lines to output to the console and we can see that "should" be getting fired but it seems to get lost somewhere.

benbjohnson commented 13 years ago

I was hoping the tcpdump would show the data going across the wire. I tried Wireshark before but I'll give it another try. Also, I'll be at 360|Flex next week so hopefully I can find someone from Adobe who knows what is going on.

GogKurt commented 13 years ago

I can get the packet data but its quite a lot to post here, I'll see if I can clean it up a little first.

GogKurt commented 13 years ago

I think we've confirmed this is a policy issue. I've got a verbose tcpdump

http://pastie.org/1767186

We're also printing messages to the console which reads:

About to call Melomel.connect().....
[Melomel Bridge : connect] host : localhost port : 10101
Melomel.stage : [object Stage]
Melomel.stage.stageWidth : 640
Melomel.stage.stageHeight : 360
[Melomel Bridge : connect] host : localhost port : 10101
[Melomel Bridge : connect] host : localhost port : 10101
|...
[Melomel Bridge : connect] host : localhost port : 10101
[Melomel Bridge : connect] host : localhost port : 10101
[Melomel Bridge : SECURITY_ERROR] : Error #2048
[Melomel Bridge : connect] host : localhost port : 10101
[Melomel Bridge : SECURITY_ERROR] : Error #2048
|...

I'm busy going through the following documents, which I'm hoping may help.

http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security.html

benbjohnson commented 13 years ago

Thanks, Kurt. It's definitely a security issue from the looks of your tcpdump. It does a request to port 10101 with a , Melomel returns it, and then it tries to make a call to port 843 (which is the fallback port for policy files).

I'll try looking at the packet data coming from web-socket-js or Merapi. It works fine on my Mac and I know it works for some people on Windows. This is a strange issue.

Is your tcpdump from Windows or Ubuntu?

Ben

GogKurt commented 13 years ago

That was from the Ubuntu machine which we have just got working. We changed line 70 of /usr/lib/ruby/gems/1.8/gems/melomel-0.6.1/lib/melomel/bridge.rb so that the policy reads as follows: private def send_policy_file(socket) policy = '' policy << '<?xml version="1.0"?>' policy << '<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">' policy << '' policy << "<allow-access-from domain=\"#{host}\" to-ports=\"#{port}\"/>" policy << "<allow-access-from domain=\"*\" to-ports=\"#{port}\"/>" policy << ''

I haven't tried the windows machine yet but this has cleared up the security issue for the moment.

benbjohnson commented 13 years ago

Good catch. That would make sense if it's using 127.0.0.1 instead of localhost. I'll add it back into master and push a release soon.

benbjohnson commented 13 years ago

hey guys, I just created a mailing list on librelist. You can join it by sending a blank email to melomel@librelist.com.

I'll also add it to the README and web site.

benbjohnson commented 13 years ago

@GogKurt - I integrated your changes into the Melomel Ruby library and released it as v0.6.2.

I'm now able to get intermittent connections to Melomel. It seems to work the first time but it will hang on subsequent connections. I tried using Wireshark but it turns out that Windows won't let you sniff loopback traffic without a lot of hacks. I'll have to try to figure that one out later.

Also, there's a really simple file in the code repository so that you can test if a connection makes it.

On Mac:

 $ bin/melomel

On Windows:

C:\melomel> ruby bin/melomel
benbjohnson commented 13 years ago

I was finally able to get this one figured out with the help of @adamflater. It turned out to be a race condition caused by an auto-retry implemented on the socket bridge. I removed the auto retry for now. It's typically never used anyway.

The changes have been released to Melomel SWC v0.6.6. You'll still need to implement the gist mentioned by Simon Gregory above until a Windows runner is implemented directly into the Melomel code.

Please let me know if anybody has any more problems.