Skynet is a framework for distributed services in Go.

Refactoring of InstanceMonitor to use a single notification channel and a callback method to keep the exposed interface from having to know anything about the InstanceListener object, and monitoring many channels.

Also refactored instancesocket.go to support cleaning up after timeouts, and stale web sockets that failed to read/write, this refactoring also includes modifications so that it uses the new InstanceMonitor implementation

Several changes to the logging inside dashboard that were merged from andrey's branch

Doozer is primary and makes most sense - but we should support some other options - via interface, selectable at generation time. Redis is a good choice because it supports push on changes. Others should be supported by implementing the interface.

to remove hard mongodb dependency from skynet, and to use skynet to keep the logger up itself, let's make the mongologger a wrapper to a skynet client, that sends it's requests through skynet rpc to a distributed mongo logger service that does the actual interaction with mongodb

This is my first pull request so feel free to let me know what I've done wrong :) I tried to keep the code duplication down by splitting GetServiceConfigFromFlags into two.

I was having issues with the default Vagrantfile setup with all the non-main VMs trying to connect to a mongo on localhost that was hardcoded---the mongo server is only running on one of the 5 vms.

cheers, leo

Change the generator to be interactive. Instead of a bunch of ugly and hard to remember command line flags, let's use an interactive generator that builds up enough information to make a skynet mesh. This might be the highest bang for the buck right now.

According to http://golang.org/cmd/go/#GOPATH_environment_variable :

If the GOBIN environment variable is set, commands are installed to the directory it names instead of DIR/bin.

The command sky deploy should check the environment variable GOBIN first.

I added a quick mango initiator example. It's basically quick copy/paste hack-job of the other one. Figured it was the least I could do to contribute. :)

On executing the following (as listed in the wiki)

go get github.com/4ad/doozer go get github.com/4ad/doozerd

Go throws an error stating

go/src/pkg/github.com/4ad/doozer/msg.pb.go:10: undefined: proto.GetString

Without Doozer, I can't run SkyNet :-(

Right now, Skynet chooses a simple route randomly. May be very useful to choose routes other ways... perhaps by using a data center metric that gives affinity to closer nodes? More thought required on this.

I believe I've found an issue that shows up when trying to send megabyte-scale messages in Skynet.

Skynet version: 2cf329fcc Environment: OSX Lion 10.8.2 64-bit Intel Go: go1.0.3

The minimum case is:

1. create a service which accepts some payload containing an array of bytes
2. create a client which makes an RPC call sending a payloads of around 6MB of binary data
3. the service will receive and process the payload correctly, but a following message will be sent to the service with a bogus (and in most cases, gigabyte) packet size

I modified the bsoncoder.go file to print out the byte-shifted data length, and it is getting a phantom second message with an very large packet size:

skynet: 2013/02/02 20:42:21 trace: Service "Art" registered
BSON LENGTH = 5
req = &{ServiceMethod: Seq:0 next:<nil>}
BSON LENGTH = 49
BSON LENGTH = 6656246
req = &{ServiceMethod: Seq:0 next:<nil>}
skynet: 2013/02/02 20:42:26 trace: Method "Put" called with RequestInfo &{127.0.0.1:49159 127.0.0.1:49159 c96ea8d1-187d-4b87-9d40-9247e675cb20 0}
BSON LENGTH = 3242877185
panic: runtime error: makeslice: len out of range

The 6656246 value is the valid RPC call; the next BSON message being decoded is the spurious call. I also looked at the BSON length array; the 4th array element is 255 which gets left-bit-shifted by 24 bits and which creats this erroneous packet. I don't know where this message is coming from; the client is making a single RPC call.

I have a (possibly) minimum sample program, which I will attach to this ticket. Instructions for use:

1. Create a binary data file called bigfile.bin; I did this with: dd if=/dev/random of=bigfile.bin bs=1024 count=6500
2. Compile the client: go build -o client.bin ./client
3. Compile the service: go build -o artd.bin ./artd
4. Ensure that Skynet is up and running (on localhost)
5. Start the service: ./artd.bin
6. Execute the client: ./client.bin

The service will crash. So will the client, but that's because of a panic being thrown when the service connection errors out.

Source code for minimum case demonstrating the problem can be fetched from Google Drive: http://goo.gl/sorXf

Create interface for remote logging, and single implementation using mongodb capped collection. Interface should allow any implementation, first impl will be MongoDB capped collection.

Build Log viewer with searching into web UI.

skynet service hadn't GetServiceConfig function, it change to NewServiceInfo.

func main() {
    tutorial := &TutorialService{}
    config := skynet.NewServiceInfo("TutorialService", "1")
    config.Region = "Development"
    service := service.CreateService(tutorial, config)
    defer func() {
        service.Shutdown()
    }()
    waiter := service.Start()
    waiter.Wait()
}

However, I found the exception , panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x0 pc=0x4f0a9e]

I want to really start looking at skynet; (should I be using skynet2).

however I cannot see any clear docs on Getting Started; (Either golang or the Ruby)

In a nut shell I want to run on my local machine create some Services and see what I can come up with.

what are the easiest coolest steps to get this going? I think this would really helpful for people that want to get to grip oon this beast

Thanks

Add functionality so we could possibly do "sky command FOO" and because it's not a recognized command it would be forwarded along to the service.

This would allow implementors to leverage sky for custom things they may want to enable or disable etc.

Rather than a direct string comparison we should investigate doing something like

https://github.com/jm/go-semver

so that we can have more loose version requirements