What's the main difference between bidirectional and directional sockets?

Question

Bidirectional means the data incoming and outgoing data flows over the same channel (sockets), in classical socket it is the case. For example you want to connect to a server: you create a socket, send and receive the data over the same channel. Is that not bidirectional?

What's different to websockets (bidirectional), only that they are runnable on browsers? Is that the difference?

Another question is what happens during bind() on serverside; is this used to say to the TCP-Stack Implementation of OS, to which socket the messages have to be passed on that port?

Answer 1

Bidirectional means data flows in both directions, whereas Unidirectional means data flows in only one direction. A socket is created as a bidirectional resource (capable of both sending and receiving), even if it is only used in a unidirectional manner in code. You can optionally use shutdown() to close one direction of data flow if you are not going to use it (ie, shutdown(SD_SEND) on a receive-only socket, or shutdown(SD_RECEIVE) on a send-only socket).

A WebSocket is still a socket, just one that runs in a web browser, and whose transmitted data has to be framed in a particular format according to the WebSocket spec. A WebSocket can send/receive arbitrary data, just like an ordinary socket can, it just has to have the data wrapped in frames that need to be decoded on the receiving end.

bind(), whether called on the client side or the server side (yes, it can be called on both), tells the OS which local IP/Port pair to associate with the socket before the connection is established. A socket is uniquely identified by its socket protocol type (UDP, TCP, etc), its local bound IP/Port pair, and its connected remote IP/Port pair. Network packets that do not match an established socket connection are discarded.

On the client side, calling bind() is optional, as connect() will bind implicitly if bind() has not been called. bind() is useful if the client has multiple network adapters installed and wants to specify which one to connect out with, or if the client must use a specific local port (dictated by data protocol, firewall rules, etc).

On the server side, bind() is required, to establish the IP/Port that the server listens on to accept clients on.

Answer 2

Websockets are an attempt to work around the pull model of HTTP, e.g. where the client does an HTTP query and the server does an HTTP response and that's the end of the talk. But often more than that is needed, e.g. server push or just classical bidirectional communication not limited to request+response. In a world without firewalls, one would use classical sockets for this task, but in today's world lots of communication is restricted and direct connections to arbitrary ports will not work anymore.

Websockets work around this problem by upgrading an established HTTP communication. E.g. the client requests an HTTP upgrade, and if the server agrees both can talk from now on inside this HTTP connection like they would do with a simple TCP connection. In reality, they have some framing and data mangling inside, but this detail is hidden from the user. In a way, it is similar to the CONNECT method used by browsers to establish an (https) tunnel through a web proxy.

Of course, this means that a Websocket connection can only be established between a web client supporting the protocol (most recent browsers do) and a web server implementing Websockets. This especially means that you cannot use WebSockets to connect to UDP sockets or to arbitrary TCP sockets (unless the web server forwards these data). But this also means, that if you upgrade an HTTPS connection to WebSockets, the WebSockets connection will be transparently SSL protected too. But, even if the client and server are supporting Websockets the connection upgrade might fail, if there is a web proxy in between which does not understand WebSockets or will explicitly block them.

In case you understand german https://blog.genua.de/blog/post/loecher-in-der-firewall-mit-websockets.html might give you an interesting read about how Websockets fit in the network stack and about their security implications.