I\'m about to host a small socket server on a local computer and I\'d like to know what kind of bandwidth it\'s going to use. On most days it will have no more than 50 clients
WebSockets can stay open for a very long time, so handling a large number of concurrent connections usually means you'll need to scale out that service to accommodate for the increased load. This is the same for almost any technology, but there's usually a limit to the max number of open connections a server can handle before things go downhill quickly. If you're likely to have such peaks in traffic, I'd consider looking into a 3rd party service like pusher or kaazing (disclaimer: I haven't tried either yet.)
You've posted a pretty vague question (we know nothing about your application, architecture, etc. - just expected traffic), but hopefully that helps point you in the right direction. That being said... based upon your use case (broadcasting one or two small messages, occasionally), my gut is telling me that WebSockets are not the right technology for you.
(Note that bandwidth probably shouldn't be a concern - generally speaking if you were to send many messages over WebSockets vs. REST you'll be sending less data due to headers, cookies, etc.)