This is what I couldn't find when I wanted to do the subscribe stuff.

http://tools.ietf.org/html/draft-ietf-core-observe-05

Options are 4-bit numbers specifying the delta from the previous option to the current one. There are provisions in the protocol for having deltas > 15 IDs apart, but this implementation does not currently have them.

can you introduce something about block in coap. i don't know how to send a big file with this package.
thank you.

The library doesn't parse/skip token when parsing a message. Fixed in https://github.com/teslaworksumn/go-coap

Is go-coap support dtls ?

As specified in the RFC, confirmable message should be retransmitted until receiving an Acknowledgement with the same message ID

                        Client              Server
                           |                  |
                           |   CON [0x7d34]   |
                           +----------------->|
                           |                  |
                           |   ACK [0x7d34]   |
                           |<-----------------+
                           |                  | 

The sender retransmits the Confirmable message at exponentially increasing intervals, until it receives an acknowledgement (or Reset message) or runs out of attempts.

ResponseTimeout const control message response timeout and it is set to 2 seconds.

While 2 seconds timeout is ok for 1st message, when message is re transmitted the timeout value needs to be increased. Thus, we need to be able to supply custom ResponseTimeout with the request data as it appears to be a higher level function in this API design.

const (
	// ResponseTimeout is the amount of time to wait for a
	// response.
	ResponseTimeout = time.Second * 2
)

// Receive a message.
func Receive(l *net.UDPConn, buf []byte) (Message, error) {
	l.SetReadDeadline(time.Now().Add(ResponseTimeout))

	nr, _, err := l.ReadFromUDP(buf)
	if err != nil {
		return Message{}, err
	}
	return parseMessage(buf[:nr])
}

What's the best way to reach and extract URL parameters in cases like /users/:user_id/message - how to get this user_id in the handler?

Will /users/:user_id/message and /users/:address/home call the same handler?

Is there a good reason for ParseMessage being private? I'm using the parser and it's a quiet convenient method. I would like to see it public.

As specified in the IETF draft: https://tools.ietf.org/html/draft-ietf-core-block-17, sending a single large file split into multiple blocks that fit into UDP packets.

On Server Side How to define Resources or Endpoints and write handlers in specific to those endpoints using your library?
And also on Client side how to write data to particular endpoint or resource?

Can you write a sample server-client program with Endpoints included.

A TCP version of CoAP is under specification:
https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-02

The message format is not so different, would be nice to support it

Adding a handler with path "/" will result in a "http: invalid pattern " panic:

package main

import (
	"log"
	"net"

	"github.com/dustin/go-coap"
)

func main() {
	mux := coap.NewServeMux()
	mux.Handle("/", coap.FuncHandler(handler))
	log.Fatal(coap.ListenAndServe("udp", ":5683", mux))
}

func handler(l *net.UDPConn, a *net.UDPAddr, m *coap.Message) *coap.Message {
	log.Printf("%s-%d: %b", a.String(), m.MessageID, m.Payload)
	return nil
}

When I try coap-client connect to coap-server(in example) panic is occured! (In Go1.4)

panic: invalid type for option 8: []string ([some path])

goroutine 5 [running]:
github.com/dustin/go-coap.option.toBytes(0x8, 0x4f7660, 0xc20801e280, 0x0, 0x0, 0x0)
/home/work/gosrc/src/github.com/dustin/go-coap/message.go:242 +0x32b
github.com/dustin/go-coap.(*Message).MarshalBinary(0xc20803c320, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/work/gosrc/src/github.com/dustin/go-coap/message.go:410 +0x315
github.com/dustin/go-coap.Transmit(0xc208038028, 0xc20803a3f0, 0x30394502, 0x0, 0x0, 0x0, 0xc208045290, 0xd, 0x10, 0xc20803a480, ...)
/home/work/gosrc/src/github.com/dustin/go-coap/server.go:47 +0x6b
github.com/dustin/go-coap.handlePacket(0xc208038028, 0xc20803a420, 0x25, 0x25, 0xc20803a3f0, 0x7f9238a8ab18, 0x597fb0)
/home/work/gosrc/src/github.com/dustin/go-coap/server.go:41 +0x30b
created by github.com/dustin/go-coap.ListenAndServe
/home/work/gosrc/src/github.com/dustin/go-coap/server.go:89 +0x2de

goroutine 1 [IO wait]:
net.(_pollDesc).Wait(0xc2080100d0, 0x72, 0x0, 0x0)
/home/work/go/src/net/fd_poll_runtime.go:84 +0x47
net.(_pollDesc).WaitRead(0xc2080100d0, 0x0, 0x0)
/home/work/go/src/net/fd_poll_runtime.go:89 +0x43
net.(_netFD).readFrom(0xc208010070, 0xc20805686c, 0x5dc, 0x5dc, 0x0, 0x0, 0x0, 0x7f9238a8aac8, 0xc2080450a0)
/home/work/go/src/net/fd_unix.go:269 +0x4a1
net.(_UDPConn).ReadFromUDP(0xc208038028, 0xc20805686c, 0x5dc, 0x5dc, 0xc20803a3f0, 0x0, 0x0, 0x0)
/home/work/go/src/net/udpsock_posix.go:67 +0x124
github.com/dustin/go-coap.ListenAndServe(0x55f730, 0x3, 0x556d10, 0x5, 0x7f9238a8ab18, 0x597fb0, 0x0, 0x0)
/home/work/gosrc/src/github.com/dustin/go-coap/server.go:85 +0x19c
main.main()
/home/work/gosrc/src/github.com/dustin/go-coap/example/server/coap_server.go:27 +0xa5
exit status 2

You're not suppose to have / in paths, but instead to break it into parts.

In example/obsserver/obsserver.go, line 42-45:

if value, ok := m.Option(coap.Observe).([]uint8); ok &&
					len(value) >= 1 && value[0] == 1 {
					go periodicTransmitter(l, a, m)
}

The type assertion gives a false for okay and a wrong value. This causes the if-clause to fail, and so the function periodicTransmitter is never called. I changed the code like this to get it to work:

obss := fmt.Sprint(m.Option(coap.Observe))
value, err := strconv.Atoi(obss)
if err != nil {
	log.Fatalf("Could not convert observe value to int", err)
}
if value == 1 {
	go periodicTransmitter(l, a, m)
}

with imports of fmt and strconv.

I'll suggest to implement the interfaces BinaryMarshaler and BinaryUnmarshaler from the encoding/binary package hence it enables users to get the byte representation without sending and vice versa.

IMHO this is nicer than writing custom encode- and decode-functions.

If you like my idea, i would provide a pull request for that.

I've been putting most of my efforts into mqtt lately and haven't spent any time in CoAP. There appears to be a lot of interest here. Does anyone want to help push this forward?

Receive() in client.go uses a hard-coded response timeout of 2 seconds. This needs to be either way higher or, better yet, user-specifyable. Dealing with, e.g., wireless sensor networks doing time-slotted channel hopping (TSCH protocol), responses don't come in that quickly.

@dustin We have generated some data using go-coap client and the data is not reaching Java-Calfornium-Coap Server. Though the go-coap client is working perfectly fine with go-coap server and node-js coap server, it is not working with Java Server.

More over the go-coap is not throwing any error also. And We don't see any data on the Java-server side from go-coap client.

Not sure this is in-scope for what you're doing, but looks like there is draft support for websockets as a protocol which seems really interesting http://www.ietf.org/id/draft-savolainen-core-coap-websockets-05.txt