sockets

[mwieder]

Ditto on the awesome.

And... if you can give me client and server sockets I can give you in-app debugging.

[LCMark]

@monte: I've pushed the changes to get notify.cpp (and therefore DNS resolution in the socket code) to work on iOS to the feature-externals_api_v5 branch in my repo (it builds on the previous changes)... I'd hoped to have time to pull out the notify-related changes separately today as a separate branch, but that wasn't to be. I'll see if I can tomorrow morning though.

[LCMark]

@runrevmark: if you tell me where to look, I'll see if I can help untangle the Java synchronization stuff

Turns out it isn't java synchronization related... But more the attempt to use the JNI on a thread that Java knows nothing about - the Android VM doesn't seem to like that much

[DarScott]

I think this means I should stop work on the iOS sockets external and script library.

[monte]

@DarScott I possibly wouldn't have done mergSocket if I knew you were still working on darzSockets... Anyway, it's done now and engine sockets make both redundant which is a good thing in my opinion.

[DarScott]

Yeah, it is a good thing that sockets are in the engine, especially now that there is a mechanism for getting fixes for obscure bugs. And simple enhancements like broadcasting (assuming that is a good and proper thing, even with an allowBroadcast property if that makes moralizers happy).

And as for darzSockets, I only recently got back to it. It works, but I wanted to make something with some of the same quirks as the engine version. And by going to partial blocking, the LiveCode level can be greatly simplified.

[monte]

OK, got sockets working on iOS... testing between desktop and simulator. But there seems to be a strange delay occasionally between the new connection callback on desktop and the socket open callback on the simulator... most of the time it's immediate but occasionally there's a fair wait... any ideas why that would happen?

[splash21]

It's great that you guys are looking at sockets. One useful addition would be the ability to specify the local port to be used when connecting to a remote server - bug 5097 : http://quality.runrev.com/show_bug.cgi?id=5097

If that's possible, it would open up a whole load of P2P possibilities - the same way as Skype and others do it.

[monte]

doesn't look overly complicated... why not give it a crack John?

[LCMark]

OK, got sockets working on iOS... testing between desktop and simulator. But there seems to be a strange delay occasionally between the new connection callback on desktop and the socket open callback on the simulator... most of the time it's immediate but occasionally there's a fair wait... any ideas why that would happen?

Great! This is going to make lots of people happy I think

In regards to the delay, then this is quite likely due to the event loop not being interrupted on the iOS side so there's a delay until some other event happens. In the callback that processes the socket events from CoreFoundation, is there a 'pingwait()'? This method causes any pending 'wait()' to be broken and thus events to be processed on the engine side.

[monte]

That was it... so opening sockets seems to work now... still something going on with the callbacks from accepting them so I'll look into that

[monte]

I see the new openSSL branch... I suspect this means mobile [ssl] sockets, encryption etc are on the way... Will this make 6.5?

[LCMark]

@monte: Yes - after much fiddling around I finally got OpenSSL (latest version) compiling for all platforms with a collection of build scripts. Thus far I've got as far as getting encrypt/decrypt working for iOS, sockets still need some more poking. There's still a fair bit to do since the standalone builder needs tweaking as well (to handle the additional, optional, revsecurity blob), but if not in 6.5, I'm hoping to get it all done for 6.6 which should follow not too long after.