networking

[christophberger]

Written on 02/25/2017 14:50:35

URL: https://appliedgo.net/networking/

[christophberger]

Migrated comment, written by Povilas Versockas on 03/14/2017 07:12:36

Hey,

Great post! I really like that you used gob package.

There is a little mistake in Step 2, it should be "cd $GOPATH/src/github.com/appliedgo/networ..." not "cd $GOPATH/github.com/appliedgo/networ...".

[christophberger]

Migrated comment, written by Christoph on 03/14/2017 08:25:06

Thanks for letting me know! I fixed it.

[christophberger]

Migrated comment, written by 独行的蚂蚁 on 12/08/2017 03:59:18

Your blog looks nice, thank you for the article.

[christophberger]

Migrated comment, written by gxvrtplkfdawr gxvrtplkfdawr on 05/04/2018 16:03:38

return errors.Wrap(err, "Unable to listen on "+e.listener.Addr().String()+"\n") - on this line will be runtime error because listener is nil.

[christophberger]

Migrated comment, written by Christoph on 05/07/2018 19:45:55

You are right - this would work if listener was a struct, but here, listener is an interface, and a nil interface contains no implemented methods. I will update the article as soon as i will have sorted out an issue with my blog post generator code.

[christophberger]

Migrated comment, written by gxvrtplkfdawr gxvrtplkfdawr on 05/16/2018 20:45:52

Hmmm, why we need lock here, AddHandleFunc is not concurrently?
e.m.Lock()
e.handler[name] = f
e.m.Unlock()

And why we need lock here?
e.m.RLock()
handleCommand, ok := e.handler[cmd]
e.m.RUnlock()
It is just read?

[christophberger]

Migrated comment, written by Christoph on 05/20/2018 17:05:38

Indeed, AddHandlerFunc is not called in a concurrent way in this code (that is, there are no other goroutines running at that point that would also access the map). But if you would take the unprotected call and use it in a context where concurrent code is already executing, then the mutex is necessary.

Regarding the lock when reading e.handler[cmd], this is only a read lock. Multiple readers can hold a read lock at the same time, so they do not block each other. However, a writer that requests a write lock has to wait until no more read locks are active.

[christophberger]

Migrated comment, written by youmoo on 05/07/2019 04:42:19

Very easy to understand. Can I translate this article to Chinese? I will provide the original link to this article. Thanks

[tribals]

Interesting post and layout - but example is really overcomplicated. Despite author states that "it should do something useful" - rarely "accepting strings over TCP socket" is that. Another catch is on mutex - is it really needed? Why to lock before adding new handlers? It looks like "it is because I can" kind of reason.

[christophberger]

@tribals Author here. Thank you for your comments.

The code is eight years old, and today I would certainly do a few things different. This being said, keep in mind that the code is meant for learning purposes, which means it's using recommended practices like guarding access to a map with mutexes. If someone extends the code to dynamically register handlers while the server is running, these mutexes would be dearly needed. If I rewrote the code today, I would just hard-code the handlers for simplicity.

Regarding "accepting strings over TCP", the purpose of TCP connections ultimately is to send and receive... data. Strings are data, and gobs are data. TCP doesn't care what payload it carries. Strings are perfectly valid payload—think of simple monitoring services or networking with IoT devices. Think of SMTP, IRC, the Memcached protocol, or Redis' RESP protocol, which all exchange plain text over TCP. Even HTTP is just plain text from a TCP perspective.

So for the sake of not overcomplicating the article, I decided to focus on the basic mechanisms without adding higher-level protocols to the scenario, which, for the purpose of demonstrating TCP functionality, is neither required nor doing any good.