Sockets with std.net in Zig 0.13.0

[purpux]

I’m a bit confused on how to create sockets with std.net in Zig 0.13.0. There are no tutorials for 0.13, only 0.12, and from what I can see, std.net has changed in this verison.

Right now, I’m using just the regular posix functions to create my UDP sockets. You know, the regular socket(), bind() and then connect() if I’m on a client or just recvfrom() if I’m making the server.

Is there any tutorial and / or resource to see how this works ? Because I can’t seem to decipher exactly what I’m supposed to do with std.net. The only thing I figured out is that std.net.Address is a wrapper for C’s struct sockaddr.

Just pointing out resources or even just telling me if std.net should be used at all would be helpful. Then I’ll just use posix without worrying if there is a correct “Zig way” of doing things.

[Sze]

I haven’t really used it a lot yet, but these topics seem related:

Is this error expected?

const std = @import("std"); const net = std.net; const posix = std.posix; const mem = std.mem; pub fn main() !void { var addr = try net.Address.parseIp("127.0.0.1", 33333); const socket_fd = try posix.socket(addr.any.family, posix.SOCK.STREAM, posix.IPPROTO.TCP); const socket_len: posix.socklen_t = addr.getOsSockLen(); try posix.setsockopt( socket_fd, posix.SOL.SOCKET, posix.SO.REUSEADDR, &mem.toBytes(@as(c_int, 1)), ); try posix.bind(s…

This one is a bit older, back then a bunch of functions were in std.os that are now in std.posix:

UDP Socket Server in Zig

The following is a working example that wait for one packet, displays it and exits. const std = @import("std"); pub fn main() !void { const addr = try std.net.Address.parseIp("127.0.0.1", 55555); const sock = try std.os.socket(std.os.AF.INET, std.os.SOCK.DGRAM, std.os.IPPROTO.UDP); defer std.os.close(sock); try std.os.bind(sock, &addr.any, addr.getOsSockLen()); var buf: [1024]u8 = undefined; const len = try std.os.recv(sock, &buf, 0); std.debug.print("{s}\n", .{buf[…

I think for these sorts of things the cookbook is often a good starting point:

UDP Echo - Zig cookbook

[purpux]

Thank you so much !

I actually had a look at the “UDP Socket Server in Zig” post you were talking about, but they used Zig 0.11 and 012, and also mostly used std.posix and std.os.linux.

The first post has a poor title, but it was also using just posix. I wish people titled their posts better lmao :D.

I also didn’t know there was a Zig cookbook, so that helped quite a bit. I will probably refer to that quite a bit from now.

Seems like networking in Zig is just using posix, which I don’t mind. I’m familiar with it.

Thanks for the fast reply !

[Sze]

There is also this library which seems quite popular:

GitHub - ikskuh/zig-network: A smallest-common-subset of socket functions for...

[ThinhNguyenHoang1]

Hey, I am author of the first post here. I do also greatly regret the post title after creating it (was quite passed out when posting it)

About your post, I greatly recommend this series on low level network programming with zig (even thought it is about TCP, not UDP but I believe it is still very useful) if you haven’t seen it already:

TCP Server in Zig - Part 1 - Single Threaded

The author also provides his insights about the current state of std.net abstraction (and why should you use lower-level posix API instead) which I fully agree with.

[purpux]

This is a cool library, and I do need both Linux and MacOS support. I’ll probably give this a shot in my project. Thanks !

[purpux]

Don’t worry about the title lmao. It happens to the best of us.

As you said, the article you recommended basically answered my question about std.net, namely the fact that it is incomplete. I disagree that we should use the posix api though, reliable cross platform net code would have been so much better. You can’t always trust an OS to properly implement POSIX…

That leaves me with the choice of either using a library or writing my own network abstractions.

I think I’ll probably write my own abstractions because MacOS sockets are mostly just more posix stuff anyways, and I can probably get away without changing much code. As long as I don’t run into any posix breaking stuff on MacOS of course :D.