C or C++ version???

[CoolJavelin]

This is a wonderful idea to allow Windoz boxes to see *nix stuff.

However, Python is an interpreted language, and as such, uses up a lot of ram when running (due to the interpreter) and also, is generally slow.

Something like network discovery should be written to be as small and fast as possible, as it is so closely linked to the OS.

Is there a C++ version? Or any intention to make it C (or C++.)

I think from a performance and size point of view, C would be better then C++, but either would be better then Python.

Of course, I do get the compatibility issue. This (Python) will run on anybody's computer even without installing, and compiling C for all the variants of *nix's out there is definitely a PITA.

Mark.

[christgau]

trl;dr wsdd will be Python in the future also because speed is not a concern.

However, Python is an interpreted language, and as such, uses up a lot of ram when running (due to the interpreter) and also, is generally slow.

I struggle with such general statements. Python is a language at first instance. Then there are implementations that bring Python to live, with CPython being the most prominent example of a Python interpreter and PyPy being a JIT compiler. They differ in the implementation and the speed they deliver. There are claims that PyPy can be even faster than C, but I won't judge on such statements here.

I can agree that CPython evidently consumes more memory and code execution needs more efforts compared to machine code like generated by C. But: Do you really need to care about that fact having the particular use case in mind?

Something like network discovery should be written to be as small and fast as possible, as it is so closely linked to the OS.

IMO, network discovery is not something special that is more closely linked to the OS than any other network software. In addition, I would claim that wsdd is quiet "small" in the sense that there is not a lot of bloat around its core functionality. Further, it uses IO multiplexing/is event-based which makes it already quiet efficient from the networking point of view.

Moreover, I do not see concerns w.r.t. to speed or why wsdd should be (extremely) fast here. We are talking about a use case in a local network, likely in a consumer/home user environment. Does it make a difference if a host is discovered some milliseconds sooner or later? The underlying protocol and requirements from the Windows side are also not very concerned about speed. It is more the opposite way around: Keep in mind that the protocol was also intended to be run on devices with limited capabilities like printers, scanners etc. Since you may run wsdd on a file serving/Samba host which is very likely to be even more powerful in terms of processor and memory than such hardware I would assume you would hardly notice any speed difference compared to a C implementation. In that sense I do not see a necessity to optimize for speed here. We are not speaking of a production-ready enterprise scale webserver software that should serve several thousands of requests per seconds.

Btw: Personally, I run wsdd on a host with a 266 MHz i586-compatible single core processor and 128 MB RAM and not running Samba on it. wsdd consumes around 3 MB RSSAnon (16 MB peak) on it, but it works flawless. The whole Probe/Resolve/MetaDataExchange cycle is performed within 300 ms. That's definitely acceptable from my point of view, especially if I look at devices like a Raspi Zero which has 1GHz and 512 MB RAM. If you really need a smaller memory footprint (and faster reply) than you may take look at C implementations...

Is there a C++ version? Or any intention to make it C (or C++.)

Yes. Other people developed C versions. Take a look at https://github.com/Andy2244/wsdd2/, e.g. It is IMO based on a NetGear implementation.

I think from a performance and size point of view, C would be better then C++, but either would be better then Python.

See my statement above. From my point of view, one should not make such statements that language X is generally slower/faster/better/whatever than language Y. We are talking about languages. How can one text representation of an algorithm be better than another wrt to performance. You need some sort of compiler to get that text to execution on a CPU. And what happens if you use a straightforward, non-optimizing C compiler and compare the performance of the generated binary with the one generated by a fully-fledged C++ compiler. Would that lead to the conclusion that C++ is better than another. And even if you take reasonable evolved compilers, the answer to "which language [out of C/C++] is faster" is: It depends

Putting that aside, (C)Python is very likely to be outperformed by a C and C++ but I do not see that the impact for wsdd would be high or of relevance.

Of course, I do get the compatibility issue. This (Python) will run on anybody's computer even without installing, and compiling C

It will run on every machine with a Python implementation that provides all the required modules. In fact that was one of the motivations of using Python here. Since it is widely supported you can basically drop the script somewhere and let it run. Another motivation was productivity, especially having to deal with XML. You can have a lot of "fun" if you to handle XML on your own in C, especially if you take it serious and respect all the things that XML can surprise you with. So in the end you (or at least I would) have to use an XML library which complicates building on different systems and porting wsdd to different OS. Ahh, and not to forget: You need a HTTP server as well which you can either implement on our own or use libraries which is what Python provided to me.

To sum up my lengthy elaboration: I don't think it is required to optimize for speed and size here. If that is really a requirement, there are other implementations out there. Choose the one that fits your purposes. Since wsdd is primarily a side project for me, a port to another language is not really on my agenda. I considered C++ a while ago but I wanted to go for the networking TS there which hadn't materialized at that time in any compiler/runtime.