i want to use websockets in my java application, but have to specify the TOS flag. Is there a common way to do this properly? how do i configure socket settings typically?
thanks in advance!
This can be done with the setTrafficClass(int) method from the java.net.Socket class. The JavaDoc has a good description of the allowed parameter values and what it refers to:
For Internet Protocol v4 the value consists of an octet with precedence and TOS fields as detailed in RFC 1349. The TOS field is bitset created by bitwise-or'ing values such the following :-
• IPTOS_LOWCOST (0x02)
• IPTOS_RELIABILITY (0x04)
• IPTOS_THROUGHPUT (0x08)
• IPTOS_LOWDELAY (0x10)
The last low order bit is always ignored as this corresponds to the MBZ (must be zero) bit.
Related
I wish to check if a user's Java version is at least 1.8.0_171. I mean that specific iteration or higher, meaning 1.8.0_151, for instance, would not work.
I planned to originally use org.apache.commons.lang3.SystemUtils' isJavaVersionAtLeast(JavaVersion requiredVersion) method, but it seems that you cannot specify the iteration number.
Based on this and Java's changing way of representing version numbers in Java (e.g. 1.8 then 9), what is the best way to check the Java version of the user in the Java program?
Edit:
This was marked as a duplicate of this question; however, I think it is different in that it asks how to compare the java version with a certain version given the changes in format of how the java version is shown.
Even with the versioning change, I think the solution is still as simple as using the following boolean expression:
"1.8.0_171".compareTo(System.getProperty("java.version")) <= 0
If the user's java.version property is any less than 1.8.0_171, then the above expression returns false, and vice versa. This works for using "9" or "10" in place of the java.version property as well.
Today I was reading the documentation for Netty's Base64Dialect class.
It includes a dialect called ORDERED, of which it says, somewhat briefly:
Special "ordered" dialect of Base64 described in RFC1940.
To cut to the chase, I can't find any definition of what this is, and includes an erroneous reference which seems to replicated all over the internet.
Instead of RFC-1940, the document actually links to RFCC-1940, which apparently is a "reader comment", and a nonsensical one at that:
RFC 920: whkpiy clujzis brkyh dwojfmz jydwq hrnwcgklt fsltaiu
Comment by lsnxkrjo sxavymwpg
Submitted on 10/26/2006
Related RFC: RFC-920
Now RFC-920 appears to have nothing to do with base 64:
Domain requirements
This memo restates and refines the requirements on establishing a
Domain first described in RFC-881. It adds considerable detail
to that discussion, and introduces the limited set of top level
domains.
Is RFC-1940 relevant? Skimming, no I can't see any base 64 encoding definitions here:
Source Demand Routing: Packet Format and Forwarding Specification (Version 1).
The purpose of SDRP is to support source-initiated selection of
routes to complement the route selection provided by existing routing
protocols for both inter-domain and intra-domain routes. [...]
In fact, searching the web for "rfcc 1940 ordered base64" finds this same URL in lots of other documentation, but sadly no explanation of "lexically ordered base 64".
Is there a legitimate definition of this anywhere? And why hasn't anyone else noticed this URL refers to nonsense?
I have not found a "legitimate definition" of ordered Base64. (At time of writing this, it is not even mentioned in the Wikipedia page on Base64.)
If you treat the code as a specification(!), ordered Base64 is a variant in which the alphabet has been reordered into ascending ASCII order. This means that the natural ordering for ordered Base64 is the same as the natural ordering for the corresponding byte sequence.
Is it a problem that there isn't a specification for ordered Base64?
Probably not.
In reality the RFCs that "specify" the different variants of Base64 (and Base32 / Base16) are actually more of an attempt to describe the variants rather than specify them. And the same applies to the Wikipedia article.
From what I can tell (google searches), the ordered Base64 variant is rarely used.
The Base64 implementation that introduced the ordered variant is legacy code. (It hasn't been changed in the last 8 years). New Java code that requires Base64 encoding / decoding capability should be using the standard Java java.util.Base64 class introduced in Java 8.
But it is concerning that the javadocs you linked to (and others!) all refer to a nonsense page. That page probably had a legitimate description at some point, but it looks like it has been vandalized.
The documentation at this page states that
Any value may be set using the corresponding set<Value> method.
However, I am not sure how to interpret this statement. I have tried the following but none of them compile, and nor did I expect them to.
certificate.set3();
certificate.setThree();
serverCertificate.set<3>();
What is the correct method call to set the version number explicitly?
You can not. It explicitely says:
This class represents a X.509 version 3 certificate, as specified by
ISO/IEC and ANSI X9.
Update:
Seems that you can not actually set the version. It "configures" itself the proper version depending on which extensions you use. In V1 there were no extensions and in V2 just few.
The version number per default is set to 1 indicating a Version 1
certificate. When including subjectUniqueID or issuerUniqueID, the
version automatically will be set to 2, and when adding an extension
increased to 3.
In BSON Java implementation, an ObjectId is composed by 3 pieces (source code: http://grepcode.com/file/repo1.maven.org/maven2/org.mongodb/mongo-java-driver/2.9.0/org/bson/types/ObjectId.java#ObjectId.%3Cinit%3E%28int%2Cint%2Cint%29 ):
XXXX XXXX XXXX
-------------------------
time machine&pid inc
(each X represents a byte)
this is a bit different from what's described in document (doc: http://docs.mongodb.org/manual/core/object-id/ )
XXXX XXX XX XXX
--------------------------
time machine pid inc
(each X represents a byte)
Can anyone let me know why the java-driver didn't follow the spec?
Thanks!
I will put this as answer since it is a bit long for a comment.
There are a couple of JIRA links to this:
https://jira.mongodb.org/browse/JAVA-81
https://jira.mongodb.org/browse/JAVA-337
The second acknowledges that the spec is different under Java however makes no reference as to why.
If I were to make a guess it could be due to the way the PID and machine id in Java works, it could be related to: https://jira.mongodb.org/browse/JAVA-586.
You may find your answer better on the Google Group: mongodb-user since the maintainers hang out there.
I expect the original intent of an ObjectID was to generate a reasonably unique primary key, rather than packing fields that drivers would then start parsing as data.
As the MongoDB ecosystem has evolved, some developers have found it useful to interpret the ObjectID from multiple drivers as well as ensure consistency of generated IDs.
If you look at the BSON spec you will see there are a few subtypes for UUID used by older drivers, and various changes for interoperability. For example, there is mention on PYTHON-387 of supporting "legacy" byte orders and endianness for the C# and Java drivers.
As per JAVA-337 in the MongoDB issue tracker, the Java driver's ObjectID inconsistency is planned to be addressed in the 3.0 Java driver release.
I cannot explain why they are different, but I can tell you that the Python driver generates object ids using the same approach that the Java one does:
https://github.com/mongodb/mongo-python-driver/blob/master/bson/objectid.py
Well I notice in Java and presumably other languages there is a Socket option similar to
setTrafficClass(int tc)
I know the application I am using has a traffic class of 24, however despite googling I cannot find a list of what these classes correspond to, nor a list of valid ones.
Please enlighten me.
md_5
According to the specification for Socket.setTrafficClass, we see:
For Internet Protocol v4 the value consists of an integer, the least significant 8 bits of which represent the value of the TOS octet in IP packets sent by the socket. RFC 1349 defines the TOS values as follows:
IPTOS_LOWCOST (0x02)
IPTOS_RELIABILITY (0x04)
IPTOS_THROUGHPUT (0x08)
IPTOS_LOWDELAY (0x10)
The last low order bit is always ignored as this corresponds to the MBZ (must be zero) bit.
24 is 0x18 i.e. 0x10 | 0x08, which corresponds to IPTOS_THROUGHPUT and IPTOS_LOWDELAY being set.
As you can see, the TOS only serves as a hint; it requests high-throughput, low-delay routing... which may or may not be serviced!
You can read more on types of service in RFC 1349 and the relevant Wikipedia article here.
The Javadocs have some details. Essentially, you're setting the TOS (type of service) header of your packet. The routing network may choose to use that as a suggestion on how to process the packet (or it might ignore it completely). A lot of networks don't actually do anything meaningful with this field, so I wouldn't rely on it's behaviour.
Traffic class is ultimately a matter between you and your nearest router. The field has been through several mutations. It also varies between IPv4 and IPv6. The first definition for IPv4 was given in RFC 791-5; this was revised in RFC 1349, and redefined completely in RFC 2474 as 'Differentiated Services'. The whole business may well have been revised again since I researched it for my book in 2003 or so. For IPv6 see RFC 2460. The stuff in the Javadoc about the IPTOS_* values refers to RFC 1349, and was already several years out of date when it was written.