Can a TCP socket client and protobuf talk to a gRPC server? - sockets

I have two machines talking to each other over TCP, with Machine A using Machine B's service. Ideally I'd love to use an RPC framework for this. gRPC comes to mind since we already use protobuf.
However, Machine A already uses an external library that wraps TCP sockets for communication, so that the client app code can only send raw bytes (encoded in protobuf) to Machine B. So I wonder if I could adapt the code to working with the gRPC server on Machine B.


gRPC is built on top of http/2, and you can theoretically use any kind of connection (e.g. domain sockets, named pipes) to communicate using gRPC, so it is certainly possible. In fact, at least in go, gRPC uses TCP by default.
If the requirement is only that machine A communicates using TCP sockets, but you can use external libraries, then it should be fairly easy to use the gRPC library of the language of your choice to implement the client/server interaction on top of the raw TCP sockets.
On the other hand, if you can not use the gRPC library, while still possible you would have to implement the gRPC protocol yourself, and possibly the http/2 one as well if you can't use any external library; this would likely be a lot of work, and you may be better off creating a simpler, ad-hoc RPC protocol for your use case.
EDIT
The updated question makes the requirements clearer. If you need to use a specific TCP library, but you can use gRPC on top of that, then I think the difficulty of the task really depends on the programming language.
For instance, in go it would be as easy as creating a wrapper struct, implement the net.conn interface for it, and use it with the withDialer option when creating the client. In c++ it looks like it would be more difficult and entail implementing a custom transport (altough I'm not that familiar with the c++ gRPC API so there may be an easier way)

Related

How to use sockets in Lean?

How do I create a TCP socket in Lean 4 and accept an incoming connection or connect to a remote address? In other words, how do I implement a TCP server or client in Lean 4?

You need to wrap the socket types and functions to use them in Lean 4.
Lean 4 is still in an early stage, even without a stable release. There is very few packages for Lean now, so you cannot expect production level packages like Python's socket or Rust's std::net/mio.
But if you just want to take a try, you can look at my lean4-socket package, which is a toy implementation. There are also simple examples e.g. sending HTTP request (which is based on TCP) in the examples folder.

There is a rudimentary but working implementation of a socket API here which you can use with Lean 4 and Lake. It also has two examples that demonstrate its use.

Does VSCode use blocking communication with LSP

I'm playing around Language Server Protocol. After playing around for sometime I can see two way to communicate with the Language server, which is blocking sockets and non-blocking sockets.
By blocking socket I mean sending request and block until response. This is easy but It will block the UI once I use it in GUI application. Another one is using async/non-blocking sockets. This is a bit complex and might require some callback/event mechanism.
Now my question is which way does VSCode use to communicate with LSP?

The node language server implementation used by many extensions uses non-blocking communications. You can find the implementation here. It uses nodejs streams and the net module

Sockets vs websockets, what is the difference, advantages?

I am having a hard time figuring the motivation behind websockets. From what I've read around the web, regular sockets are still faster and more efficient, so in short, why would I want to use websockets, when and where?

And regarding why to bother with websockets:
It's mainly because browsers only support the Websocket API in their Javascript APIs and do no provide direct TCP socket support.
This was done to prevent (possibly malicious) Javascript apps to create any kind of TCP connections which could provide them confidential information and forward it to the internet.
With Websockets Webapps can only connect to websocket servers. The websocket protocol uses an obfuscation mechanism that prevents that webapps can send any kind of raw TCP data.

Sockets are a lower level. They can work with any type of netwroking. Websockets are at a higher level. They power web servers, and drive web apps. A websocket can be made via plain sockets. It is jsut a lower/higher level thing. Websockets are more of a convience thing. They require you to write less code

ZMQ sockets with custom load-balancing

I looked at ZMQ PUSH/PULL sockets and even though I quite like the simplicity (especially compared to custom fragmentation/ack I am implementing right now in a system over UDP sockets), I would like to have custom load balancing instead of the naive round-robin (I believe) that ZMQ PUSH/PULL sockets are using.
I am new to ZQM and not sure how I can implement it using ZMQ sockets and if it's even possible at all. What I would ideally like is, the serving PUSH socket (or some other socket type) determines (based on the messages etc.) which machine to send the message to.
So my questions are:
Is this possible?
If so, what ZMQ pattern would work best for it?
How can I use those sockets?

If you want to have custom routing, you have to use ROUTER sockets, and then use IDENTITY-based routing.
There is an example in the Guide illustrating how to build simple LRU routing with a ROUTER socket (i.e. behaves the same as PUSH). You would just need to write your own logic for deciding which worker IDENTITY gets each message.

Difference between socket and websocket?

I'm building web app that needs to communicate with another application using socket connections. This is new territory for me, so want to be sure that sockets are different than websockets. It seems like they're only conceptually similar.
Asking because initially I'd planned on using Django as the foundation for my project, but in the SO post I linked to above it's made very clear that websockets aren't possible (or at least not reliable, even with something like django-websockets) using the preferred Django setup (Apache with mod_wsgi). Yet I've found other posts that casually import Python's socket module for something as simple as grabbing the server's hostname.
So:
Are they really different?
Is there any reason not to use Django for a project that relies on establishing socket connections with an outside server?

To answer your questions.
Even though they achieve (in general) similar things, yes, they are really different. WebSockets typically run from browsers connecting to Application Server over a protocol similar to HTTP that runs over TCP/IP. So they are primarily for Web Applications that require a permanent connection to its server. On the other hand, plain sockets are more powerful and generic. They run over TCP/IP but they are not restricted to browsers or HTTP protocol. They could be used to implement any kind of communication.
No. There is no reason.

Websockets use sockets in their implementation. Websockets are based on a standard protocol (now in final call, but not yet final) that defines a connection "handshake" and message "frame." The two sides go through the handshake procedure to mutually accept a connection and then use the standard message format ("frame") to pass messages back and forth.
I'm developing a framework that will allow you to communicate directly machine to machine with installed software. It might suit your purpose. You can follow my blog if you wish: http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html

WebSocket is just another application level protocol over TCP protocol, just like HTTP.
Some snippets < Spring in Action 4> quoted below, hope it can help you understand WebSocket better.
In its simplest form, a WebSocket is just a communication channel
between two applications (not necessarily a browser is
involved)...WebSocket communication can be used between any kinds of
applications, but the most common use of WebSocket is to facilitate
communication between a server application and a browser-based application.

You'd have to use WebSockets (or some similar protocol module e.g. as supported by the Flash plugin) because a normal browser application simply can't open a pure TCP socket.
The Socket.IO module available for node.js can help a lot, but note that it is not a pure WebSocket module in its own right.
It's actually a more generic communications module that can run on top of various other network protocols, including WebSockets, and Flash sockets.
Hence if you want to use Socket.IO on the server end you must also use their client code and objects. You can't easily make raw WebSocket connections to a socket.io server as you'd have to emulate their message protocol.

WebSocket is a computer communications transport protocol (like TCP, HTTP 1.0, HTTP 1.1, HTTP 2.0, QUIC, WebRTC, etc.)
Socket is an endpoint for sending and receiving data across the network (like Port number)
Example of Socket:
(TCP, 8.8.8.4, 8080, 8.8.8.8, 8070)
where:
(protocol, local address, local port, remote address, remote port)

Regarding your question (b), be aware that the Websocket specification hasn't been finalised. According to the W3C:
Implementors should be aware that this specification is not stable.
Personally I regard Websockets to be waaay too bleeding edge to use at present. Though I'll probably find them useful in a year or so.