Is the folder actually there after a restart? I think it might be in the sandbox which changes paths between restarts?
ohh s… i am so stupid, sure you are right!! its fixes now, i think its time to start some ios testing, when somebody like you can send me your udid and i will prepare the .ipa for testing.
I’ll try and get one, as I don’t own an iDevice, but I am more interested in the approach and changes required than I am in testing.
Is syncthing compiled using cgo or the native go compiler, etc? Will be possible to package up syncthing for the app store? I know there is a lot of guidelines and signing bullcrap that it needs to go through?
Looking forward to the blog post.
Compiled with CGO and Signed with xCode directly.
I have pushed a Tax-Calculator to the App Store Process, Apple says nothing, all good until now and the App is full Go Source also compiled with CGO.
So in this case i think in the next weeks, i will push it to the App Store… Just to try and see what Apple say…
I have not so much time but i will try to write it on my Blog http://fucking-stuff.com is called by the way… i am sorry when i am not allowed to write the Domain here…
If this is to be published on the App Store as “Syncthing”, I’d much prefer if you contributed the build process plus whatever GUI wrappers as a repo under the syncthing Github organization, so we can do official releases from there and keep the version in step with the core version.
3 Likes
sure i will do this for syncthing and i hava also implemented a cross plattform qrreader without flash in the source, so i will pulish this to.
and i think there are much more people which want to port there go app to ios, so i need to contrubute this process to.
Please publish the code for what you’ve done 
@victormatheus
Give me a little bit time please, i want to fix some stuff before i puplish the source, i don’t like that after puplishing i must answer 1000… question
@All is there a function which i can call, just to restart the gui http server? I can’t restart the hole syncthing, otherwise it exit…
You should be watching for Syncthing’s exit code, and restart it if it indicates that it wants a restart.
I think his stuff is in the same binary. It’s not like syncthing-android where part of it is in a separate process.
@sgilani I don’t think you can do that, why do you need to do that though?
The point is the iOS Deep Sleep Mode or Lock Button.
The App is working fine in foreground and background mode, because i am running the syncthing process in dispatch_async mode… but when the phone comes back from deep sleep, syncthing needs to restart…
This is the message: Syncthing seems to be down, or there is a problem with your Internet connection. Retrying
But the funny part is, i can see on my connected mac to the phone, that the device is online and it syncs, but the gui is not available…at this moment… i think the the webserver is dead, but i cant restart the hole thing, because with a restart the hole app exit and apple not allow me to restart a app automaticly again.
Do you access syncthings log? You can run it with STTRACE=http,suture env var and see what happens.
I have a hunch that iOS kills the listening socket, and we fail to restart, the reason syncing works is because we dial out (rather than listening), which is also an issue which we should fix, so that we restart listening.
Same goes for discovery I guess.
The logs should have some clues, especially this line:
you are definitely right, it is the listening… and now?
Well logs would be helpful, as I’ve said.
i have no logs in the moment, i must change the path for logs to in syncthing.
[HDFNX] 13:55:16 INFO: API listening on [::]:8384
2015-07-09 14:55:18.367 IDZWebBrowser[521:44818] -[IDZWebBrowserViewController webViewDidFinishLoad:]
2015-07-09 14:55:23.437 IDZWebBrowser[521:44818] -[IDZWebBrowserViewController webViewDidFinishLoad:]
[HDFNX] 13:55:30 INFO: UPnP read: read udp4 0.0.0.0:57039: recvfrom: socket is not connected
[HDFNX] 13:55:30 INFO: UPnP read: read udp4 0.0.0.0:65141: recvfrom: socket is not connected
[HDFNX] 13:55:30 INFO: UPnP read: read udp4 0.0.0.0:63612: recvfrom: socket is not connected
[HDFNX] 13:55:30 INFO: UPnP read: read udp4 0.0.0.0:58463: recvfrom: socket is not connected
[HDFNX] 13:55:30 INFO: Local discovery (broadcast reader): read udp4 0.0.0.0:21025: recvfrom: socket is not connected
[HDFNX] 13:55:30 WARNING: multicast read: read udp6 [::]:21026: recvfrom: socket is not connected
[HDFNX] 13:55:30 WARNING: multicast read: read udp6 [::]:21026: recvfrom: socket is not connected
[HDFNX] 13:55:30 WARNING: multicast read: read udp6 [::]:21026: recvfrom: socket is not connectedIs this after the sleep?
yes after the deep sleep
Yeah, this will be trouble-some. The way we usually handle this, is detect that more than N seconds passed between our N second sleep and restart, this way rebuilding all connections. There is sadly no other way to do that at the moment. We’re in progress of converting current components to suture services which allows us to restart components while live, but we are not fully there yet.
Though this should be handled for the web server as far as I understand, unless there is some bug where accept calls block indefinitely even for a closed socket. In which case we could just add a for loop around accept setting a timeout conn.SetDeadline(time.Now().Add(1 * time.Second)) and retrying if the error returned by accept was a timeout error.
I guess it would be nice to have a list of things that break, so that we could prioritize them.
Is your implementation of the iOS app going to be open source? I’d like to help work on it if possible.
Note also that with Go 1.5, the Go compiler can create native iOS apps, GUI and all. I haven’t tried it myself so I don’t know how painful it is to work with, but theoretically a fully native Syncthing is viable.
1 Like