[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648684#action_12648684
]
Emmanuel Lecharny commented on DIRMINA-539:
-------------------------------------------
I think that all those checks (can we set/get traffic class on a
socket/datagram) is totally useless. Either you can, or you can't, but in the
second case, it simply does nothing.
Now, the current implementation is totally FU, because we do things like :
public void setTrafficClass(int trafficClass) {
if (DefaultDatagramSessionConfig.isSetTrafficClassAvailable()) {
try {
c.socket().setTrafficClass(trafficClass);
...
with :
public static boolean isSetTrafficClassAvailable() {
return SET_TRAFFIC_CLASS_AVAILABLE;
}
and, ultimately :
private static final boolean SET_TRAFFIC_CLASS_AVAILABLE = false;
^^^^
This is a dead end : the isSetTrafficClassAvailable() will always return false.
Here is what I suggest : we simply get rid of all those controls, and let the
user set/get the traffic class at will. If the underlaying network does not
support it, well, it's fine, no harm.
> NioDatagramConnector doesn't takes the TrafficClass value set to his
> DatagramSessionConfig
> -------------------------------------------------------------------------------------------
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
> Reporter: martin krivosik
> Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
> Original Estimate: 0.33h
> Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the
> config, so the ToS byte is not set in the packet sent from client.
> client code:
> NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
> DatagramSessionConfig dcfg =
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
> dcfg.setTrafficClass(tosByte);
> InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP,
> port);
> acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in
> the packet.
> (the same problem may be in the socket, i have to check it)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
