DHCPV4: Missing some useful New*FromRequest server functions about dhcp HOT 11 CLOSED

Hey @begetan, thanks for the suggestion! A server implementation is coming shortly, I have a work-in-progress pull request waiting on some other stuff before being merged. That includes also some of the functions you are suggesting, but I will add only the ones that are strictly necessary for the server code. Of course we can add more of them later on. For now just stay tuned, I plan to merge the v4 server around next week

from dhcp.

Wouldn't NewOfferFromRequest and NewAckFromRequest be the same as NewReplyFromRequest plus setting the message type? I don't see much added value in having those functions.

from dhcp.

I believe that at the time we opened this issue we didn't have NewReplyFromRequest, I'm closing this

from dhcp.

We did have it, it is mentioned in the issue description.

from dhcp.

oh, good point. Either way we don't need those functions, thanks for noticing!

from dhcp.

Wouldn't NewOfferFromRequest and NewAckFromRequest be the same as NewReplyFromRequest plus setting the message type? I don't see much added value in having those functions.

In order to create acknowledge from NewOfferFromRequest we have to set 2 fields, 3 Options and one Option list according to parameter OptionParameterRequestList

It looks like this:

r, err := dhcpv4.NewReplyFromRequest(p)
r.SetYourIPAddr(ip)
r.SetServerIPAddr(h.ip)
r.AddOption(&dhcpv4.OptMessageType{MessageType: dhcpv4.MessageTypeAck})
...
3 more lines of code 

Packet structure is incomplete after NewReplyFromRequest(p).
It should be assigned extra settings to create a valid DHCP packet.
The order of settings is important. User should care enough about byte handling.

The Idea is to provide in library higher level function which can deliver complete packet.
So user can focus on server logic rather that byte handling.

In the same time there is a client function NewRequestFromOffer
This function includes option settings and makes completed packet for DHCP client reply,
so user of the library doesn't care about byte encoding in client library.

I am just interesting about the reason of discrimination server library.

from dhcp.

NewReplyFromRequest is intended to be used as a base function when implementing a server handler. How the Offer and Ack looks like may change according to the server implemenation.

A pull request is always welcomed. How would you suggest NewOfferFromRequest and NewAckFromRequest should look like? Will they be very different from each other?

from dhcp.

I agree that it would be nice if server implementations could focus on logic rather than packet, even if I don't see it as a blocker. Details may still differ, and even the server implementation cannot ignore wire-level details.
If we have to implement wrappers, this should probably go one layer up, in a sub-module.

However, regarding server implementation, stay tuned, as I have been working on CoreDHCP, a server implementation based on this library

from dhcp.

@pmazzini

NewOfferFromRequest only differ from NewAckFromRequest by the message type

It its possible to have only single function like NewPacketFromRequest(type MessageType, ...)
But in this case it should handle all possible types of reply including OFFER, ACK, NACK.. etc

It is just a matter of operational excellence of API structure. For my personal opinion to have 3-4 simpler methods with name exactly describing its destiny is better than one universal complicated function.

I also agree with @insomniacslk that it may be in a level up wrapper, which may be used in user defined implementation of server handler. Anyway I suppose you will come back to that decision during work on upcoming server implementation on next abstraction level. So no need to have that functions in the library right now.

from dhcp.

At this point I wonder if server and client should be separate packages from the packet parsing, and contain all the low and high level wrappers. I am reopening this issue because there's still room for an interesting discussion

from dhcp.

I wonder if server and client should be separate packages

Server and client are both different packages now. Several helper functions were added since.

from dhcp.