WASMFS socket backend and WISP

[Kveon Lichman]

Hello! Long time user of emscripten here.

I've worked on many projects in the past that required network access, for which I've used a few patches on top of SOCKFS for. However, the project seems to be heading towards WASMFS default, which does not currently support socket emulation.

I'm interested in contributing a new socket backend to WASMFS that supports the wisp protocol, a standard for tcp/udp-over-websockets, used by projects like v86 and scramjet.

Are you accepting contributions for a new backend at this time? Anything else I should know before I go into it?

[Alon Zakai]

A socket backend for WasmFS sounds good! We'd definitely be interested in such a contribution.

I am not familiar with wisp, but would that need to be part of WasmFS? If wisp is a protocol on top of websockets, could it be a library in userspace (i.e. not part of the system)?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/45b5a7c4-d3d2-40af-ac05-35f5f309561bn%40googlegroups.com.

[Kveon Lichman]

My plan is to have WISP implement the network connect/send/recv syscalls, so you can give full TCP/UDP network access to an existing app just by adding a flag.

I think you could do it just with EM_JS, but you'd have to write your own set of syscall handlers / file descriptor table / proxy plumbing (which WASMFS already implements), and it would require modifying every place the application uses sockets. 

[Sam Clegg]

IIUC the plan is to have WASMFS support the existing filesytems writting using the JS filesystem API?   So maybe we you can just write it against the current libfs.js API and it will *just* work after in both old and new filesystems.

IIUC for JS filesystems (both old and new ones) that need to run on the main thread (or at least one specific thread with proxying), we might as well use the existing JS filesytem API shape?

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/572886e5-c650-41c9-8ed7-b9be4279436bn%40googlegroups.com.

[Kveon Lichman]

Makes sense, I'll look into doing it at that layer. My only concern is the 64 fd socket limit which can be pretty annoying to deal with in network-heavy apps. Would the eventual WASMFS->libfs.js layer bypass that restriction?

[Alon Zakai]

On Tue, Jul 7, 2026 at 9:33 AM 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com> wrote:

IIUC the plan is to have WASMFS support the existing filesytems writting using the JS filesystem API?   So maybe we you can just write it against the current libfs.js API and it will *just* work after in both old and new filesystems.

That is one proposed idea, but we don't have a proof of concept of it yet. In theory, it might not work out.

But, I agree that if it did, it would make work like this simpler. Perhaps it makes sense to add that compatibility layer now, then just use the existing JS sockets backend in WasmFS?

 

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-sQ%2B-C6D1k%2BvvcMUGj0myiFZtDsDhNEbSqGn0qbN0sEA%40mail.gmail.com.

[Sam Clegg]

Where/what is the 64 fd socket limit you are referring to?

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/112290ab-7dc6-453a-9375-3a8fdf1068cen%40googlegroups.com.

[Kveon Lichman]

In select() https://github.com/emscripten-core/emscripten/blob/382503cd331758af2397302f84caeb824354d34b/src/lib/libsyscall.js#L357 it will throw with a fd > 64, but a lot of C using select() assumes up to FD_SETSIZE sockets will work. Originally I thought it was a fundamental limitation wirth the architecture although looking at it now it seems like it should just be safe to remove that check / bump it to FD_SETSIZE?

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28_iikLR9ajUkzVqDR%2BGaV-D%2BvSoUiTqwefcdkBptPsfA%40mail.gmail.com.

[Sam Clegg]

Yes, if you want to increase FD_SETSIZE I think we can probably find a way to do that. 

However, it might make more sense to switch to something more modern like epoll if you are juggling a lot of FDs like that: https://github.com/emscripten-core/emscripten/pull/27207

Also, given that musl itself has a fixed FD_SETSIZE I'd be somewhat surprised if real world software out there requires it to be larger.

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAE_HM%2BR8eksuiacypuA_V_sT0r7HuX%3DQ8MUr7afzDHYQfUkdSQ%40mail.gmail.com.

[Sam Clegg]

I just notices the man page for select contains:

```
       WARNING:  select() can monitor only file descriptors numbers that are less than FD_SETSIZE (1024)—an unreasonably low limit for many modern
       applications—and this limitation will not change.  All modern applications should instead use poll(2) or epoll(7), which do not suffer this
       limitation.
```

We should support the same limit in emscripten.. I'm not quite sure whats going on with the 64 constance you linked too..

[Kveon Lichman]

Yes, emscripten seems like it should be able to support the regular 1024 limit but that assert will throw if there are more than 64. Smells like legacy cruft? My apps work fine if I just patch out that assert and use the regular limit.

[Sam Clegg]

On Tue, Jul 7, 2026 at 2:08 PM Kveon Lichman <kveo...@gmail.com> wrote:

Yes, emscripten seems like it should be able to support the regular 1024 limit but that assert will throw if there are more than 64. Smells like legacy cruft? My apps work fine if I just patch out that assert and use the regular limit.

Yup, you are exactly right:  https://github.com/emscripten-core/emscripten/pull/27272

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/5bb52e73-6ab3-4653-add2-5d579daf013en%40googlegroups.com.