<p>I created a very simple chat server that uses websockets, and clients can simply connect using a browser:
<a href="https://github.com/indy-golang/simple-chat">github/indy-golang/simple-chat</a></p>
<p>I made this for a presentation for Indy (Indianapolis) Golang meetup. If you live in the Indianapolis area you are welcome to come!
<a href="http://www.meetup.com/Indy-Golang/events/221026891/">Indy Golang April 7 meeting</a></p>
<hr/>**评论：**<br/><br/>drwiggly: <pre><p>Nice, fyi i don't think the join and leave are safe. You're accessing the map directly should probably have a RWMutex for add remove (write), and use read when doing the broadcast.</p></pre>elcct: <pre><p>Or channels like in my chat application:</p>
<p><a href="https://github.com/elcct/taillachat/blob/master/controllers/chat.go" rel="nofollow">https://github.com/elcct/taillachat/blob/master/controllers/chat.go</a></p></pre>fprotthetarball: <pre><p>This is interesting, but it seems like you're introducing a global lock on all actions by way of the channel. Locking on just the map access should be more performant.</p></pre>koffiezet: <pre><p>Channels will probably be slower...</p></pre>lacikawiz: <pre><p>Thank you for the tips! I didn't think of a race condition there.</p></pre>ricoxg: <pre><p>That's a fantastic program for teaching a slew of Golang concepts, and wish I'd seen it back when I was first learning. I'll definitely be sharing it out with a few fellow neophytes for reference.</p>
<p>Thanks for sharing!</p></pre>UserNumber42: <pre><p>I have a question. How would you go about securing something like this? If you're using js for the websocket, doesn't that mean every bit of information you send to the client is viewable by someone with even the most basic of knowledge? If you tried to implement something using tokens or salts all that information is accessible by the client.</p></pre>gogolang: <pre><p>Looks interesting! To make it more "Go" like, you should use a fully qualified path to the websocket package.</p>
<p>I wasn't able to run go get github.com/indy-golang/simple-chat</p>
<p>local import "./websocket" in non-local package</p></pre>lacikawiz: <pre><p>I'm fully aware that it's not a good practice but I wanted to make it dependency free. </p>
<p>To be honest, I do not like the way <code>go get</code> works, and I'm eagerly looking forward to the solution to the vendoring debate.</p></pre>avrtno: <pre><p>There is no debate that absolute paths should be used when vendoring. Change the import to "github.com/indy-golang/simple-chat/websocket". </p></pre>robvdl: <pre><p>I am just wondering, why on earth would you write a websocket chat server from scratch, instead of just using gorilla websockets?</p></pre>om0tho: <pre><p>Because you can't do this.</p>
<pre><code>import "github.com/gorilla/websocket"
func main() {
websocket.ChatServer()
}
</code></pre>
<p>Gorilla websockets just buys you the websocket connection, not the whole chat server.</p></pre>robvdl: <pre><p>Sure, but I guess my question is, why re-invent the wheel and do the low-level websocket code again, when you could just build the chat server on top of existing gorilla websockets code. I guess I didn't quite word my question that well.</p></pre>Bromlife: <pre><p>Really cool. When I first started looking into coding in Go this was the exact kind of thing I looked for to learn goroutines, but I couldn't find anything that helped. This would have been perfect. Chatservers make sense for learning concurrency. </p></pre>mgutz: <pre><p>Here's a good article on the subject that explains the basics </p>
<p><a href="http://gary.burd.info/go-websocket-chat">http://gary.burd.info/go-websocket-chat</a> </p></pre>lacikawiz: <pre><p>Thanks! </p>
<p>I hope it will be useful for other future Gophers :-)</p></pre>
