The server handler should only be able to craft a response packet and should not receive a net.PacketConn about dhcp HOT 6 OPEN

Hi @begetan,

I wanted to rewrite my example DHCP server with recently added server.go implementation but found no code for sending packet back to network.

Have a look at server_test.go, you can send packets back to the network using the conn net.PacketConn. We definitely need to improve the examples/documentation, which is being tracked in #188.

from dhcp.

Basically what @pmazzini said. I will write examples soon (days hopefully).
Handling errors and messages at the moment can be done implicitly with channels, but I agree that it would be nice to have them explicitly from the handler. I will have a look at that too

from dhcp.

Because of the above, @begetan could you please rename this issue to reflect what has to be done, or close this and reopen a new one? Thanks!

from dhcp.

@pmazzini
I've checked server_test.go and understood you way of handling replies.
Since I am coming to this library from other project I just trying to adopt my code based on current knowledge.

In my point of view there are some quite reasonable abstraction levels for public API:

1. DHCP bytes handling - basic functions for protocol bytes manipulation
2. DHCP messages packet handling (client/server) - basic functions for creating and investigation of real packets
3. Network support (client/server) - helpers to provides Network/OS specific logic
4. Server/Client logic - at this level users write their server or client implementation

There is one already open discussion about implementation of 1 and 2 level in library: #186

But here I would like to open another discussion about implimentation of layers 3 and 4.
In my humble opinion it is expectable to have one level functions in the same level of abstraction in code, like conn.ReadFrom and conn.WriteTo. According this logic user handler should get packet for processing and return back new packet to the library.

I just showed an example of separation logic between layer 3 and 4 including Interface method to handle server level configuration. But let's focus on architecture first because it's most important for quite new library. I believe your code implementation is much more professional than other projects and you want to share experience for wide range of programmers. So it should be structured well.

from dhcp.

@begetan Do you mean that the server handler should only be able to craft a response packet and should not receive a net.PacketConn? If that is the case then I kind of agree.

Can the issue title be properly updated?

from dhcp.

@pmazzini

After better thinking and evaluation of current implementation I see no reason to pass global server parameters to user handler. It depends on concurency model and user architecture. But now I am definitely sure about handling only packet structure, not connections.

from dhcp.