Adding WASM support

[csking101]

Referencing #61

We had discussed about whether our crate can support WASM. This PR creates a demonstration of the same.

Instructions to run

1. Firstly, you need to have wasm-pack installed. It can be found here. Simply run cargo install wasm-pack. This is used to create the WASM files based on our target (which in this case is the web). It also has the potential to create WASM files for different targets as well such as NodeJS.
2. Next, you must create the WASM file. This can be done by running wasm-pack build --target web. It will create WASM binaries in ./pkg/.
3. Finally, we must have index.html served by a simple Python server to avoid CORS issues. This can be done by running python -m http.server in the same directory as index.html.
4. Go to the URL given by the Python server as you should see a simple HTML page like this:
   
5. Click the Dissect Packet button to see this:
   

My Analysis

• For this demonstration, I had to use the ./pkg/scalpel.js, created by wasm-pack. I tried loading the ./pkg/scalpel_bg.wasm file directly into the script, however, I was facing some import issues. It turns out that WebAssembly is not yet integrated with <script type='module'> or import statements, thus there is not a path to have the browser fetch modules for you using imports. as stated in MDN Docs. Therefore, instead of tediously creating the ArrayBuffers for containing the WASM binary and following a few more steps, I ended up using the wasm-pack generated ./pkg/scalpel.js file. (However, the alternative options of loading and running the WASM binary directly can be explored)
• I have added a dissect_packet function to the lib.rs file temporarily. wasm-pack generates WASM bindings for particular functions, that have the #[wasm_bindgen] attribute. They can't be tested from examples. Therefore, we need to look into creating a separate module to provide the functions that can be used by the browser, or any other entity using the WASM file. The functions that can be supported are a point of discussion
• For demonstration purposes, I have hardcoded ENCAP_TYPE_ETH, however in the future functions that are to be written, this must be taken care of.
• Overall, our library has pretty good WASM support as we had discussed earlier. As long as we follow these guidelines, we will be good.

More areas to look into

• Testing the WASM binaries There is an error when you run cargo test --target wasm32-unknown-unknown
• Adding the testing into a CI pipeline Work on this after solving the previous issue
• Adding functions that need WASM binding generation

Further Resources

• Rust to WebAssembly the hard way
• WABT: The WebAssembly Binary Toolkit
• The wasm-bindgen Guide
• MDN Docs for Rust to WebAssembly
• Quickstart wasm-pack
• A Disallowed MIME type error that I'd faced

[gabhijit]

@csking101 : This is a great start. Thanks a lot!!

I am wondering whether it's a good idea to actually capture this into a GH discussion. Let's keep the PR open, so that it allows us to iterate, but essential discussions should be captured in discussions (because PRs once closed or merged, those discussions get kind of lost.)

I quickly looked at the cargo test --target wasm32-unknown-unknown issue. This is because of the errno dependency, which is due to pcap dev-dependency (required for examples). So we may have to wrap that into two separate feature (say wasm and pcap). And then do a cargo test per feature. I will take a shot at this. Is that cool?

[csking101]

Sure sir, that sounds great!

Also, I think we can continue in the discussions about what functions will be WASM supported, as you said, they have can different features for the same. It'll be better to segregate the two at this stage I believe.

[gabhijit]

Parts of this PR are merged with merge of #66 . Thank you for your contribution.

We can keep this PR open or move some relevant links, information to the Discussions page.