You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "martin krivosik (JIRA)" <ji...@apache.org> on 2008/03/06 15:04:58 UTC
[jira] Created: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
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
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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Edouard De Oliveira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648705#action_12648705 ]
Edouard De Oliveira commented on DIRMINA-539:
---------------------------------------------
what about this one ?
boolean setTrafficClassIfAvailable(Socket socket) {
try {
int tc = socket.getTrafficClass();
socket.setTrafficClass((~tc)&0x001E);
return (tc != socket.getTrafficClass());
} catch (Exception e) {
return false;
}
}
does the job and informs the user if not done + no unnecessary tests like the previous one which would have lead to something like
if (isSetTrafficClassAvailable(mysocket)) {
// set traffic class
....;
}
> 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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.0-M3)
2.0.0-M4
> 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: Julien Vermillard
> 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.
[jira] Assigned: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard reassigned DIRMINA-539:
-----------------------------------------
Assignee: Julien Vermillard (was: Trustin Lee)
> 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: Julien Vermillard
> Fix For: 2.0.0-M3
>
> 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.
[jira] Assigned: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny reassigned DIRMINA-539:
-----------------------------------------
Assignee: Emmanuel Lecharny (was: Julien Vermillard)
> 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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680407#action_12680407 ]
Julien Vermillard commented on DIRMINA-539:
-------------------------------------------
Agree with Emmanuel, so much glue and troubles for masking few of the complexity of a such advanced feature.
> 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-RC1
>
> 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.
[jira] Reopened: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "martin krivosik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
martin krivosik reopened DIRMINA-539:
-------------------------------------
thx very much for quick fix,
unfortunately it takes me more time to go back to this problem and verify why it does not work correctly.
in the DefaultDatagramSessionConfig
are variables
GET_TRAFFIC_CLASS_AVAILABLE
SET_TRAFFIC_CLASS_AVAILABLE
both of them are false, but only the GET_XXXX is setup according the current conditions.
the SET_XXX is never touched and therefore is not possible to set the traffic mask
in setTrafficClass() method in NioDatagramSessionConfig class since it is always false..
Since I do not understand completely the aim if your design and architecture of the lib,
I will ask you kindly to look on it and provide some fix...
> 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: Trustin Lee
> Fix For: 2.0.0-M2
>
> 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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Edouard De Oliveira (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648825#action_12648825 ]
Edouard De Oliveira commented on DIRMINA-539:
---------------------------------------------
indeed, the example was just intended to highlight the unnecesseray redundant tests happening with the use of a isSetTrafficClassAvailable(...) method.
http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#getTrafficClass()
also states that "the underlying network implementation may ignore the traffic class or type-of-service set using #setTrafficClass()"
If any error throws an exception i just wonder why the hell this code got so complicated ?
ps : tried to search through mina jira db but found nothing proving that it could fail silently
> 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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648692#action_12648692 ]
Emmanuel Lecharny commented on DIRMINA-539:
-------------------------------------------
What we can do is something like :
boolean isSetTrafficClassAvailable(Socket socket) {
try {
int tc = socket.getTrafficClass();
socket.setTrafficClass((~tc)&0x001E);
boolean supported = (tc != socket.getTrafficClass());
socket.setTrafficClass(tc);
return supported;
} catch (Exception e) {
return false;
}
}
but it seems a bit overkilling...
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.0-RC2)
2.0.0
> 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
>
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.1)
2.0.2
> 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.2
>
> 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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648780#action_12648780 ]
Emmanuel Lecharny commented on DIRMINA-539:
-------------------------------------------
Well, itwon't work :
- first, you don't pass a new traffic class
- second, I don't think that it's necessary anyway.
The contract is pretty clear :
"As the underlying network implementation may ignore this value applications should consider it a hint. "
http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setTrafficClass(int)
Let's do simple things, and when it becomes complicated, just think twice before injected convoluted code.
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.0-M2)
2.0.0-M3
> 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: Trustin Lee
> Fix For: 2.0.0-M3
>
> 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.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648934#action_12648934 ]
Emmanuel Lecharny commented on DIRMINA-539:
-------------------------------------------
The question is : do we really need this method in 2.0 (ie, isSetTrafficClassAvailable). The main problem is that we need an open socket in order to check that, and we have to set the traffic class, and reset it, to be sure that it's possible. As the Traffic Class is absolutely not guaranteed to be used by the underlying network layer, I think it's a lot of effort for a small improvement.
Now, this can be discussed. I understand that, from the user POV, masking all this complexity is good, but when a user tries to manipulate such advanced features, I think that it should be explicit.
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.0-M5)
2.0.0-RC1
> 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-RC1
>
> 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.
[jira] Resolved: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee resolved DIRMINA-539.
---------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-M2
Assignee: Trustin Lee
It should be fixed now. Please let me know if it still doesn't work as you expected.
> 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: Trustin Lee
> Fix For: 2.0.0-M2
>
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.0-RC1)
2.0.0-RC2
> 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-RC2
>
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-539:
--------------------------------------
Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1
> 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-RC1
>
> 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.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes
the TrafficClass value set to his DatagramSessionConfig
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRMINA-539:
--------------------------------------
Fix Version/s: 2.0.1
(was: 2.0.0)
Postponed to 2.0.1
> 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.1
>
> 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.