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.
Related
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)
What are the advantages and disadvantages of using only socket based communication vs a hybrid of REST and socket (using socket only when bidirectional communication is necessary, like receiving messages in a chat).
When I say only socket, I mean that instead of sending a GET request asking for /entities, I'd send update_needed and the server would send a push via socket.
My question is not really about performance, it's more about the concept, like delegate vs block/lambda (using socket would be like the delegate concept and REST is more like block).
It all boils down to what type of application and level of scalability you have in mind.
WebSocket/REST: Client connections?
How to handle CQRS from a client-side perspective
Hard downsides of long polling?
The main reason why I wouldn't use WebSockets in any major project is simply that still many users don't use a modern browser that support them. Namely IE 8 and 9 don't support them and both together still have a market share of over 20 % (Oct 15).
I want to make a social network using a server and a client in Unix C. I know how to develop some minimalistic things about this architecture, but I want to make the server concurrent. What do you guys suggest me? Of course, not an iterative model ; I'm not going to use fork neither, because the server should accept clients, read from the clients and write to the clients. What about some threading methods or multiplexing?
I would suggest you to start with multiplexing.
Take a look at these functions
select http://manpages.courier-mta.org/htmlman2/select.2.html
epoll http://man7.org/linux/man-pages/man7/epoll.7.html
You can build your server around the reactor pattern http://en.wikipedia.org/wiki/Reactor_pattern
I am implementing sockets in Lua, and the example code I'm working from uses the following method to keep the connection alive:
while true do
-- handle socket traffic here
socket.sleep(1)
end
The loop obviously prevents the rest of the project code to be run, but if I exit the loop the socket server immediately says that the connection was closed.
So how do I keep the socket open simultaneously as the rest of my Lua code runs as normal? (Is there some sort of background job support? Can coroutines be used for this purpose?)
I used Lua Lanes to start a thread that is doing the socket i/o and running in the background as you stated.
http://kotisivu.dnainternet.net/askok/bin/lanes/
Take a look at this answer, which gives info on using Lua Lanes and sockets.
LuaLanes and LuaSockets
The Dual-Threaded Polling solution provided there is probably the most viable, but, there's information about coroutines there also.
(Your question is similar to this question (and I have appropriately flagged it as a duplicate), but here's a copy of my answer for your convenience!)
There are a various ways of handling this issue; which one you will select depends on how much work you want to do.*
But first, you should clarify (to yourself) whether you are dealing with UDP or TCP; there is no "underlying TCP stack" for UDP sockets. Also, UDP is the wrong protocol to use for sending whole data such as a text, or a photo; it is an unreliable protocol so you aren't guaranteed to receive every packet, unless you're using a managed socket library (such as ENet).
Lua51/LuaJIT + LuaSocket
Polling is the only method.
Blocking: call socket.select with no time argument and wait for the socket to be readable.
Non-blocking: call socket.select with a timeout argument of 0, and use sock:settimeout(0) on the socket you're reading from.
Then simply call these repeatedly.
I would suggest using a coroutine scheduler for the non-blocking version, to allow other parts of the program to continue executing without causing too much delay.
Lua51/LuaJIT + LuaSocket + Lua Lanes (Recommended)
Same as the above method, but the socket exists in another lane (a lightweight Lua state in another thread) made using Lua Lanes (latest source). This allows you to instantly read the data from the socket and into a buffer. Then, you use a linda to send the data to the main thread for processing.
This is probably the best solution to your problem.
I've made a simple example of this, available here. It relies on Lua Lanes 3.4.0 (GitHub repo) and a patched LuaSocket 2.0.2 (source, patch, blog post re' patch)
The results are promising, though you should definitely refactor my example code if you derive from it.
LuaJIT + OS-specific sockets
If you're a little masochistic, you can try implementing a socket library from scratch. LuaJIT's FFI library makes this possible from pure Lua. Lua Lanes would be useful for this as well.
For Windows, I suggest taking a look at William Adam's blog. He's had some very interesting adventures with LuaJIT and Windows development. As for Linux and the rest, look at tutorials for C or the source of LuaSocket and translate them to LuaJIT FFI operations.
(LuaJIT supports callbacks if the API requires it; however, there is a signficant performance cost compared to polling from Lua to C.)
LuaJIT + ENet
ENet is a great library. It provides the perfect mix between TCP and UDP: reliable when desired, unreliable otherwise. It also abstracts operating system specific details, much like LuaSocket does. You can use the Lua API to bind it, or directly access it via LuaJIT's FFI (recommended).
* Pun unintentional.
The other answers are nice, but kind of miss the most important point here:
There is rarely a need nowadays to use threads when dealing with sockets
Why? Because multiple sockets are so common, that the OSes (most notably *ix systems) implemented the "multiple poll" in the form of epoll function.
All high-performance networking libraries such as ZeroMQ keep only a few threads, and operate inside them. That lower the memory requirements, but doesn't sacrifice speed.
So my suggestion would be to hook up to OS libraries directly, which is really easy in Lua. You don't have to write the code yourself - quick google search brought me this epoll wrapper [1] You can then still use coroutines to read only from sockets that actually have some data.
You might also want to take a look at ZeroMQ library itself.
[1]Neopallium created Lua bindings for ZMQ, so I think it's legit.
You can indeed use coroutines for that purpose. This is what the popular library Copas does.
Depending on your use case you can use Copas or look at its source code to see how it does it. You may also look at lua-websockets which uses Copas.
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.