pan: expose scmpHandler

[JordiSubira]

Currently both ListenUDP and DialUDP create always a default scmpHandler this is not desirable for some applications, especially some servers, that may shut down if they receive an unexpected error, e.g., a SCMPError. We expose now to the applications the scmpHandler a new parameter, if nil is providede the application will internally use the defaultScmpHandler, otherwise it will use the one the applications chooses, e.g., an handler that ignores SCMP packets.

---

This change is 

[tzaeschke]

an handler that ignores SCMP packets.
Does it make sense to include/provide a default handler for servers that does exactly that?

[tzaeschke]

pkg/pan/udp_dial.go line 49 at r1 (raw file):

// a path among this set for each Write operation.
// If the policy is nil, all paths are allowed.
// If the selector is nil, a DefaultSelector is used.

Add comment for scmpHandler?

[tzaeschke]

pkg/pan/quic_listen.go line 30 at r1 (raw file):

// See note on wildcard addresses in the package documentation.
//
// BUG This "leaks" the UDP connection, which is never closed.

Add comment that scmpHandler=nil behavior?

[tzaeschke]

pkg/pan/udp_dial.go line 50 at r1 (raw file):

// If the policy is nil, all paths are allowed.
// If the selector is nil, a DefaultSelector is used.
func DialUDP(

Is this method part of the public API? Should there be a second method, without the scmpParam, for backward compatibility?

[tzaeschke]

pkg/pan/quic_dial.go line 63 at r1 (raw file):

	selector Selector,
	scmpHandler snet.SCMPHandler,
	host string,

Same as for other functions:

• Document scmpHandler behavior (nil is recommended for clients)?
• Provide second implementation of the function with old signature? This would provide backward compatibility.

[tzaeschke]

% nitpicks

[JordiSubira]

Reviewable status: complete! 1 of 1 LGTMs obtained

---

pkg/pan/quic_dial.go line 63 at r1 (raw file):

Previously, tzaeschke (Tilmann) wrote…

Same as for other functions:

• Document scmpHandler behavior (nil is recommended for clients)?
• Provide second implementation of the function with old signature? This would provide backward compatibility.

dito

---

pkg/pan/udp_dial.go line 50 at r1 (raw file):

Previously, tzaeschke (Tilmann) wrote…

Is this method part of the public API? Should there be a second method, without the scmpParam, for backward compatibility?

It is. In Golang we don't have function overload and it is necessary to have different scmpHandling behaviour depending on the application. Whay I can do is change to a "functional options" pattern, to avoid changing the API again in the future. In any case, the signature has to change in any case.

[tzaeschke]

pkg/pan/udp_dial.go line 50 at r1 (raw file):

Previously, JordiSubira wrote…

It is. In Golang we don't have function overload and it is necessary to have different scmpHandling behaviour depending on the application. Whay I can do is change to a "functional options" pattern, to avoid changing the API again in the future. In any case, the signature has to change in any case.

Not sure what the best solution is, just wanted to point it out. Pleas do what you think is best.

[tzaeschke]

pkg/pan/quic_dial.go line 63 at r1 (raw file):

Previously, JordiSubira wrote…

dito

See DialUDP.

[tzaeschke]

Reviewed 21 of 24 files at r1.
Reviewable status: complete! 1 of 1 LGTMs obtained