-
Notifications
You must be signed in to change notification settings - Fork 1
SLP2 #20
Comments
I'll try implement SLP2, will post significant progress here (if any). |
I'm curious to see the result. As we don't have good documentation, yet, this ticket would also be the right place to start a discussion on how to specify certain aspects of SLP2. |
I made an enum member and type that had the same name but different case. The parser could not handle it. Is this by design? Not seeing this property mentioned in any docs. Snippet:
Error message:
Adding _Type suffix to types is the obvious workaround. Recall that being a popular convention. |
You're right, identifiers in RecordFlux are case-insensitive (making Regarding the |
I hit an issue I'm not sure how to solve. In RFC 2608, section 9.1 Service Location Protocol Extensions, we read:
Basically a linked list of sorts. How would I express this? |
Sometimes I wonder what went wrong in the childhoods of those protocol designers ;) The mechanism cannot be expressed with RecordFlux as is. I'd call this a feature, though, as absolute offsets to define the start of another extension is dangerous for (at least) three reasons:
I'm inclined to create some specially crafted packets and try throwing them at an implementation. However, I have no idea what SLP2 is even used for and where it is implemented. If you know any accessible implementations, I'd be interested. I don't think following the RFC by the letter is the right approach here. Do you know what implementations are actually doing? Do you have captured traces? I could imagine that this is actually just a list with the offset always pointing to the next bit after the current extension. This could be modeled by a sequence of messages (with the offset being ignored - consistency of the offset would need to be checked manually later). If the linked list is legit and indeed used, we may have to think about a way to safely express it (and generate provable code out of it which will for sure be a major challenge). |
Suspected as much. Yes, the extension mechanism has many complicated properties. Perhaps this outcome of trying to specify it in RecordFlux can provide insights for future specifications/revisions (although admittedly SLP is stale and mostly superseded by SSDP). I think pushing it to implementation is the right thing to do. The list of extensions is a continuous block of memory whose size is easily derived from the header - no problem there. And besides, the only mandatory extension - Required_Attribute_Missing - is (I think) just nicer error handling for more elaborate service providers, which I think is fine to omit. There is but one major implementation, OpenSLP. It is implemented entirely in C. I decided to try implementing an alternative in Ada, in part because of a desire to learn more Ada and SPARK, in part because I'd like a minimal, reliable implementation for lab/embedded environments (which given the open issues of OpenSLP seem unlikely). That being said OpenSLP has a command line tool that is very useful for testing an alternative implementation against a reference. Wireshark even knows how to read the fields. For what I know SLP is nowadays mostly used to locate printers on a network, though I do see potential in lab/embedded networks as means to more easily configure and modify the network. It has similarities to SSDP, which is part of UPnP. In a nutshell a client makes a broadcast/multicast request for a service matching "patterns" (is color printer, DPI this or that, located in facility X floor 2), and service providers then respond with URL (including port). Know I do this for my own pleasure. Happy as long as I learn something new. |
Having issues running test. pytest complains about
Not familiar with pytest. Could not find reference mentioning a -n flag.
Offending lines:
Probably a problem with my machine. Grateful for pointers on how to proceed. |
Several Length fields in the SLPv2 protocol hold the length of the entire message, not just a field. To constrain field size properly in these cases the field offset is subtracted:
The use of magic numbers (10) is unfortunate. One way would be to sum the size of preceding fields, though this is almost as error prone and hardly more readable. Is there a way to use field offsets in size constraints? I think Structured_Authentication_Block'Position would do what I want, but rflx does not seem able to parse it as of current. |
Seems like you're having 2 unrelated issues here.
Pytest realizes a lot of functionality through plugins. Even parallelization is done using the xdist plugin, which must be installed.
The problem is the compiler crash above, which is probably a known problem. I suspect you're using the FSF GNAT of your distribution. We only support GNAT Community Edition 2020 due to various compiler issues that our generated code triggers in older compilers. |
You can use the Structured_Authentication_Block : Opaque
with Size => 8 * Authentication_Block_Length
- (SLP_SPI_String'Last - Block_Structure_Descriptor'First + 1); (RecordFlux will throw an error regarding a potentially negative size of |
Huh. I couldn't get rflx to start on Windows so I assumed the project was Linux only. Existence of GNU Makefiles strengthened that assumption. But GNAT CE is clearly Windows only. Cygwin? Suppose I could punch a hole through WSL to use Windows GNAT install instead of WSL, but something tells me this is not how the development environment is supposed to be setup. |
It's true that RecordFlux is supported on Linux only for the time being (even though I see not fundamental obstacles to make it work on Windows or OS X). GNAT CE is available for Windows, Linux and OS X - if you go to more options on the download page, you can select the platform x86 GNU Linux (64 bits).
That sounds scary ;) |
Not the first time I missed "more options" on that very same download page.
Well, it worked! A link from gprbuild to gprbuild.exe, prefix PATH with /mnt/c/... and voila, all specs but mine pass the tests (compiling)! I installed the Linux environment just in case the problem was still something in my "unconventional" environment, but I get the same error. Spec fail to compile with this message:
Offending line:
Relevant parts of the spec (see PR for full source):
Sound familiar? Google-searches turn up almost blank on the general parts of the message. |
Wow, this is interesting to know! Congratulations for being the first Windows user of RecordFlux (for whatever it's worth ;)
This is a bug. I created a reproducer and opened AdaCore/RecordFlux#536 - we'll look into it. |
Please try AdaCore/RecordFlux@79bb58f. |
It worked! |
https://tools.ietf.org/html/rfc2608
The text was updated successfully, but these errors were encountered: