Jump to page: 1 2
Thread overview
D alternative for node.js's socket.IO?
Oct 21, 2018
Fleel
Oct 21, 2018
JN
Oct 21, 2018
Fleel
Oct 21, 2018
Neia Neutuladh
Oct 22, 2018
Neia Neutuladh
Oct 22, 2018
Fleel
Oct 22, 2018
Neia Neutuladh
Oct 23, 2018
bauss
Oct 23, 2018
bauss
October 21, 2018
Does anyone know of a good D alternative for the socket.IO server (https://socket.io)? I would like to transition my server from node.js to D, but I can't find any D equivalents to socket.IO. (I've seen http://socket.io.dub.pm, but it is dead). Are there any good D libraries that can do the same thing as socket.IO? Thanks!
October 21, 2018
On Sunday, 21 October 2018 at 20:14:46 UTC, Fleel wrote:
> Does anyone know of a good D alternative for the socket.IO server (https://socket.io)? I would like to transition my server from node.js to D, but I can't find any D equivalents to socket.IO. (I've seen http://socket.io.dub.pm, but it is dead). Are there any good D libraries that can do the same thing as socket.IO? Thanks!

Is std.socket not sufficient? It should be, at least for TCP connections. For UDP you could use something like Enet, there are Enet bindings in Derelict.
October 21, 2018
On Sunday, 21 October 2018 at 20:41:41 UTC, JN wrote:
> On Sunday, 21 October 2018 at 20:14:46 UTC, Fleel wrote:
>> Does anyone know of a good D alternative for the socket.IO server (https://socket.io)? I would like to transition my server from node.js to D, but I can't find any D equivalents to socket.IO. (I've seen http://socket.io.dub.pm, but it is dead). Are there any good D libraries that can do the same thing as socket.IO? Thanks!
>
> Is std.socket not sufficient? It should be, at least for TCP connections. For UDP you could use something like Enet, there are Enet bindings in Derelict.

Can std.socket provide a realtime connection between the client(web browser) and the server, like for a chatroom or realtime multiplayer game?
October 21, 2018
On Sun, 21 Oct 2018 20:58:23 +0000, Fleel wrote:
> Can std.socket provide a realtime connection between the client(web browser) and the server, like for a chatroom or realtime multiplayer game?

Yes, but it will be a bit of work -- you'd need to implement a webserver by hand that can upgrade an HTTP request to a websocket. It probably wouldn't be *that* hard, but vibe.d already has support for both HTTP servers and websockets.

This does mean changing the javascript code, but from what I saw last time I used it, socket.io provides little advantage over plain websockets.
October 21, 2018
On 10/21/18 4:58 PM, Fleel wrote:
> On Sunday, 21 October 2018 at 20:41:41 UTC, JN wrote:
>> On Sunday, 21 October 2018 at 20:14:46 UTC, Fleel wrote:
>>> Does anyone know of a good D alternative for the socket.IO server (https://socket.io)? I would like to transition my server from node.js to D, but I can't find any D equivalents to socket.IO. (I've seen http://socket.io.dub.pm, but it is dead). Are there any good D libraries that can do the same thing as socket.IO? Thanks!

I'm afraid I'm not familiar with socket.io, and the homepage doesn't seem to tell me much (it doesn't even say whether it uses TCP or UDP). But that said, in D, the gold-standard for pretty much *anything* related to networking and sockets is Vibe.D: http://vibed.org/

If the network/socket functionality you're looking for exists in D, then it's probably in either the standard library or in Vibe.D. If what you're looking for doesn't exist, then it can certainly be built on top of Vibe.D.

> 
> Can std.socket provide a realtime connection between the client(web browser) and the server, like for a chatroom or realtime multiplayer game?

For something like a chatroom, and the vast majority of any networking you'd want to do, Vibe.D definitely can. Plain old ordinary TCP is perfectly sufficient for something like chatrooms, and Vibe.D supports TCP clients/servers very well. For other things, Vibe.D had equally good support for UDP. So that alone makes Vibe.D universally useful, plus the way its job system works gives you all the benefits of async networking code without having to deal with the mess of callback-oriented programming.

For a realtime multiplayer games though, that's notoriously a whole different can of worms. For that, you definitely do need UDP (which again, Vibe.D supports). But, UDP being what it is, you'd still need to design your program to handle UDP's inherently unguaranteed nature. Vibe.D doesn't have a gaming-oriented networking system built on top of UDP.

You could also look into ZeroMQ: https://code.dlang.org/packages/zeromq I haven't used ZeroMQ myself though, so no promises about how well it works, but it may be worth looking into.
October 22, 2018
On Sun, 21 Oct 2018 23:05:06 -0400, Nick Sabalausky (Abscissa) wrote:
> I'm afraid I'm not familiar with socket.io, and the homepage doesn't seem to tell me much (it doesn't even say whether it uses TCP or UDP). But that said, in D, the gold-standard for pretty much *anything* related to networking and sockets is Vibe.D: http://vibed.org/

socket.io is a mix of XMLHttpRequest, websockets, and maybe long polling, based on HTTP of course. It's all Javascript, designed for a browser as a client and Node.js as a server.

When socket.io was first created, websockets were *relatively* new, and a lot of Windows/IE users were still on IE8/9, so it probably made a fair bit of sense to use a tool that could provide okay-ish support for all browsers and better support for newer browsers. But there's little reason to use it today.

The docs leave much to be desired.

> For a realtime multiplayer games though, that's notoriously a whole different can of worms. For that, you definitely do need UDP (which again, Vibe.D supports). But, UDP being what it is, you'd still need to design your program to handle UDP's inherently unguaranteed nature. Vibe.D doesn't have a gaming-oriented networking system built on top of UDP.

And since the person's probably communicating between browser clients, WebRTC is likely the most practical target there.

https://github.com/koldi/webrtc-dlang
October 22, 2018
On 10/21/18 11:59 PM, Neia Neutuladh wrote:
> On Sun, 21 Oct 2018 23:05:06 -0400, Nick Sabalausky (Abscissa) wrote:
>> I'm afraid I'm not familiar with socket.io, and the homepage doesn't
>> seem to tell me much (it doesn't even say whether it uses TCP or UDP).
>> But that said, in D, the gold-standard for pretty much *anything*
>> related to networking and sockets is Vibe.D: http://vibed.org/
> 
> socket.io is a mix of XMLHttpRequest, websockets, and maybe long polling,
> based on HTTP of course. It's all Javascript, designed for a browser as a
> client and Node.js as a server.
> 

Ahh, ok, I see. (Can't believe they couldn't have just said so on their currently-vapid homepage!) If that's the case, then Vibe.D's existing HTTP and TCP support is perfectly sufficient, and will probably also result in FAR simpler user code due to the lack of necessity for callbacks. At least on the server side, anyway. If the client side is inside a web browser, then just like ANY language that isn't JS, you'd still have have to (directly or indirectly) deal with the fact that JS/Webasm is really the ONLY Turing-complete code naively supported by modern browsers.

But, unless I'm being overly pessimistic (entirely possible), that does suggest a possible important area of improvement for libs such as Spasm: a simple no-brainer, common websockets-based API common to both client and vibe.d-based server.
October 22, 2018
On Monday, 22 October 2018 at 05:36:00 UTC, Nick Sabalausky (Abscissa) wrote:
> Vibe.D's existing HTTP and TCP support is perfectly sufficient, and will probably also result in FAR simpler user code due to the lack of necessity for callbacks

How simple is Vibe.D's method of sending messages between client and server? In socket.IO all I have to do is (on the sending side) socket.emit("testMessage", "Hi"), and on the receiving side, socket.on("testMessage", function(contents) {console.log(contents)}). Is Vibe.D as simple as this?
October 22, 2018
On Sunday, 21 October 2018 at 20:14:46 UTC, Fleel wrote:
> Does anyone know of a good D alternative for the socket.IO server (https://socket.io)? I would like to transition my server from node.js to D, but I can't find any D equivalents to socket.IO. (I've seen http://socket.io.dub.pm, but it is dead). Are there any good D libraries that can do the same thing as socket.IO? Thanks!

https://code.dlang.org/packages/hunt-grpc

Might be interesting,too?
October 22, 2018
On Mon, 22 Oct 2018 20:14:53 +0000, Fleel wrote:

> On Monday, 22 October 2018 at 05:36:00 UTC, Nick Sabalausky (Abscissa)
> wrote:
>> Vibe.D's existing HTTP and TCP support is perfectly sufficient,
>> and will probably also result in FAR simpler user code due to the lack
>> of necessity for callbacks
> 
> How simple is Vibe.D's method of sending messages between client and
> server? In socket.IO all I have to do is (on the sending side)
> socket.emit("testMessage", "Hi"), and on the receiving side,
> socket.on("testMessage", function(contents) {console.log(contents)}). Is
> Vibe.D as simple as this?

Not quite as simple; socket.io is a very slightly higher level API.

To replicate the server-side part of that, I'd write something like:

    void delegate(string)[string] handlers;
    router.get("/chatsocket", handleWebSockets((scope WebSocket socket)
    {
        while (true)
        {
            socket.waitForData;
            if (!socket.connected) break;
            string rawData = socket.receiveText;
            auto parts = rawData.splitter("|");
            auto topic = parts.front;
            parts.popFront;
            string payload = parts.empty ? null : parts.front;
            if (auto handler = topic in handlers)
            {
                (*handler)(payload);
            }
        }
    });
    handlers["testMessage"] = (s) => writeln(s);

In other words:

* We have a set of handlers. Each handler applies to a topic (one per
topic) and accepts a string of data.
* When someone connects to the "/chatsocket" endpoint, set up a websocket.
* Accept text datagrams on the websocket. They have a format of "topic|
payload", or just "topic".
* If there's a handler for that topic, send the payload to that handler.
* If there's no handler, do nothing.

You also have to know that you're not supporting browsers older than five years.

Also, that's assuming websockets are appropriate. WebRTC might be preferable for your use case (and socket.io might use that? it's difficult to tell), and that would require a lot more work.
« First   ‹ Prev
1 2