We used this library together with the Felix UPnP BaseDriver, with lots of success for a long time. As long as we only used these together. Last week we experienced lots of problems while integrating our stuff with other people using libupnp and Intel UPnP Tools, resulting in the fact they could not see our devices. We spent several hours finding the errors. These are the things we changed:
Changed:
public final String ROOT_ELEMENT_NAMESPACE = "urn:schemas-upnp-device-org:device-1-0";
Into:
public final String ROOT_ELEMENT_NAMESPACE = "urn:schemas-upnp-org:device-1-0";
***
Namspace problem:
org.cybergarage.upnp.Service.SCPD_ROOTNODE_NS:
Changed:
public static final String SCPD_ROOTNODE_NS="urn:schemas-upnp-org:services-1-0";
Into:
public static final String SCPD_ROOTNODE_NS="urn:schemas-upnp-org:service-1-0";
***
XML header
org.cybergarage.upnp.UPnP.XML_DECLARATION
Changed:
public final static String XML_DECLARATION = "<?xml version=\"1.0\"?>";
Into:
public final static String XML_DECLARATION = "<?xml version=\"1.0\" encoding=\"utf-8\"?>";
***
If some device properties aren't filled in (like Serial number or UPC or ...), they appear in the DeviceDescription XML file as <UPC /> which is off course valid XML, but Intel Tools doesn't like it this way, so we made sure all properties were filled in properly.
public String getIndentLevelString(int nIndentLevel) {
char indentString[] = new char[2 * nIndentLevel];
for (int n = 0; n < indentString.length; n++) {
indentString[n] = ' ';
}
return new String(indentString);
}
***
After having changed this, all control points were able to see our devices and UPnP functionality seemed to work OK.
When is 1.8.0 comming out?
Just a final question concerning the escaping of XML: org.cybergarage.xml.XML defines escapeXMLChars and unescapeXMLChars, but the last one is never called. What's the policy in this?
regards,
dvrslype
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi dvslype, (is it the name of a company or a nick?)
I'm very glad to herd that you're using using our code within the UPnP Base Driver from Felix (I'm one of the developer of it), but let's go back to your comment...
1 - About your changes: I'll be glad to include them in the 1.8.0-SNAPSHOT version
2 - About releasing 1.8.0, it's up to Satoshi "skonno" Konno which is the admin of the project. I don't have right for performing an official release, I could deploy a Maven release in case.
3 - About the escaping of XML, I have again to move the ball the Satoshi "skonno" Konno because he is the one owning the full picture of the project.
Ciao,
Stefano "Kismet" Lenzi
P.S.: If you have also modified the UPnP Base Driver do not hesitate to share your idea on the Felix user mailing-list or on Felix's JIRA.
P.P.S.: If you want to send a patch for your changes it will be easier for me to apply it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- How many UPnP diveces were present in the network?
- Have you encountered problem with missing UDP multicast packet (especially SSDP one)?
Me and Francesco Furfari have discovered such problem with the current implementation on a network with many UPnP devices, in fact we're planing to refactoring part of code which implement UDP communication before releasing the final 1.8.0.
Ciao,
Stefano "Kismet" Lenzi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-25
Hello,
We did not use a big amount of devices in our test network, never more then 6 or so, and never really experienced any problems with missing UDP packets. I do have a remark on the announce messages. A root device doesn't announce itself in the way is described in UPnP Device Architecture (screenshot of page 13: http://users.atlantis.ugent.be/dvrslype/UPnP/upnp.png\). Here you do not perform the second announce message. In this matter we changed this in org.cybergarage.upnp.Device.announce() somewhere around line 1220:
I currently have lots of stack traces concerning SocketException, SocketTimeoutException and ConnectException. I haven't currently figured out if the cause is in the basedriver. If I find anything, I'll keep in touch.
My current code (where I applied me changes to code i svn'ed yesterday from felix and cyberlink):
All the error SocketException, SocketTimeoutException and ConnectException comes from the CyberLink stack, and they are the same error that we get and we think that due to the many devices on our network we lose some UDP because no thread is free to listen to new messages.
It's worth to notice that not all the exception means an error on the execution of the program in fact they exception arise because the HTTP header Connection field is set to Alive but no Content-Length is provided and we have to wait till the other peer to close the connection in order to gather all the content carried by the HTTP connection.
Let me know if you get any different opinion on that, I'll really appreciate it :)
Ciao,
Stefano "Kismet" Lenzi
P.S.: I have applied all your patches proposed on this thread, I haven't checked the UPnP.rar and I have released a new SNAPSHOT version of the library (see SVN revision 63).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you say:
"[...] If some device properties aren't filled in (like Serial number or UPC or ...), they appear in the DeviceDescription XML file as <UPC /> which is off course valid XML, but Intel Tools doesn't like it this way, so we made sure all properties were filled in properly. [...]"
Do you mean that you had to changed the XML generation in order to produce XML tag like "<UPC></UPC>" or that you had to fill all the properties manually even if it was missing, with some default value like "N/A", "Unavailable", " " or "null"?
Ciao,
Stefano "Kismet" Lenzi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-26
About the Exceptions: it doesn't seem to trouble the functionality, just didn't know what they meant. I suppose I agree on that HTTP issue, nothing to do about it.
About the XML: I tried to create <UPC></UPC> by doing this in org.cybergarage.xml.Node.output around line 350:
if (value == null || value.length() == 0) {
// No value, so use short notation <node />
ps.println("></" + name + ">");
}
But it still results in <UPC /> in the xml device description.
When I try to fill in "null", <UPC>null</UPC> is shown in the device description:
if (value == null || value.length() == 0) {
// No value, so use short notation <node />
ps.println(">null</" + name + ">");
}
So I guess somekind of optimizer (XML generator) cancels this first trial out.
Not that a big issue I guess, since <UPC /> is valid XML, only some UPnP stacks don't seem to support it.
regards,
dvrslype
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If your using the Felix UPnP Base Driver, and you're compiling the code with Maven you'll automatically get the latest version because Maven looks every time for updates, if you want to be sure you can re-compile the code after a clean be executing the command:
mvn clean install
Avoiding to write empty XML could be a solution... But I have to check if it will break some code, and also I have to write it the documentation that the Node.toXMLString() generate XML String in "special" way (it skips tags with no child)
Ciao,
Stefano "Kismet" Lenzi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-10-03
On first sight, the new binary you gave me does everything I need (i.e. compatibility with Intel UPnP Tools). If there are further problems, I will report them here.
I don't use Felix build directly, I copied the source in my own build system. The current binary you provided me, is this the same as the source I can check out from the sourceforge SVN? I usually update Felix and cybergarage separately.
I have found a new issue caused in the Felix basedriver. I will post it here, should I put it somewhere else (I saw you were on the Felix team to, and I don't like the tracking system...)?
In org.apache.felix.upnp.basedriver.exportGeneralActionListener, after successfull invocation of an Action (Dictionary invoke(Dictionary)), the basedriver tries to extract the values of the outargs from the dictionary and put them in the ArgumentList object of Action. Here arises a problem when an Action has in-out arguments. In the ArgumentList these are treated seperatly (2 Argument objects with the same name, but different argument direction).
When the basedriver wants to set the value for out argument, it does ArgumentList.getArgument(argumentName) and finds the in argument rather then the out argument! So the out argument is never set, resulting in a constant null as value for the out argument.
My proposal for a fix:
on line 123:
[code]arg = al.getArgument(outArg[j]); //can be null, tries getting the argument (which can be wrong)[/code]
replace by:
[code]
arg = null;
for (int n = 0; n < al.size(); n++) {
Argument a = al.getArgument(n);
String aName = a.getName();
if (aName == null || a.isInDirection())
continue;
if (aName.equals(outArg[j]) == true) {
arg = a;
break;
}
}
[/code]
Hello,
We used this library together with the Felix UPnP BaseDriver, with lots of success for a long time. As long as we only used these together. Last week we experienced lots of problems while integrating our stuff with other people using libupnp and Intel UPnP Tools, resulting in the fact they could not see our devices. We spent several hours finding the errors. These are the things we changed:
Namspace problem:
org.cybergarage.upnp.RootDescription.ROOT_ELEMENT_NAMESPACE
Changed:
public final String ROOT_ELEMENT_NAMESPACE = "urn:schemas-upnp-device-org:device-1-0";
Into:
public final String ROOT_ELEMENT_NAMESPACE = "urn:schemas-upnp-org:device-1-0";
***
Namspace problem:
org.cybergarage.upnp.Service.SCPD_ROOTNODE_NS:
Changed:
public static final String SCPD_ROOTNODE_NS="urn:schemas-upnp-org:services-1-0";
Into:
public static final String SCPD_ROOTNODE_NS="urn:schemas-upnp-org:service-1-0";
***
XML header
org.cybergarage.upnp.UPnP.XML_DECLARATION
Changed:
public final static String XML_DECLARATION = "<?xml version=\"1.0\"?>";
Into:
public final static String XML_DECLARATION = "<?xml version=\"1.0\" encoding=\"utf-8\"?>";
***
If some device properties aren't filled in (like Serial number or UPC or ...), they appear in the DeviceDescription XML file as <UPC /> which is off course valid XML, but Intel Tools doesn't like it this way, so we made sure all properties were filled in properly.
***
Some XML parsers do not seem to accept tabs:
Changed org.cybergarage.xml.Node.getIndentLevelString into:
public String getIndentLevelString(int nIndentLevel) {
char indentString[] = new char[2 * nIndentLevel];
for (int n = 0; n < indentString.length; n++) {
indentString[n] = ' ';
}
return new String(indentString);
}
***
After having changed this, all control points were able to see our devices and UPnP functionality seemed to work OK.
When is 1.8.0 comming out?
Just a final question concerning the escaping of XML: org.cybergarage.xml.XML defines escapeXMLChars and unescapeXMLChars, but the last one is never called. What's the policy in this?
regards,
dvrslype
Hi dvslype, (is it the name of a company or a nick?)
I'm very glad to herd that you're using using our code within the UPnP Base Driver from Felix (I'm one of the developer of it), but let's go back to your comment...
1 - About your changes: I'll be glad to include them in the 1.8.0-SNAPSHOT version
2 - About releasing 1.8.0, it's up to Satoshi "skonno" Konno which is the admin of the project. I don't have right for performing an official release, I could deploy a Maven release in case.
3 - About the escaping of XML, I have again to move the ball the Satoshi "skonno" Konno because he is the one owning the full picture of the project.
Ciao,
Stefano "Kismet" Lenzi
P.S.: If you have also modified the UPnP Base Driver do not hesitate to share your idea on the Felix user mailing-list or on Felix's JIRA.
P.P.S.: If you want to send a patch for your changes it will be easier for me to apply it
Hi dvslype,
I forgot to ask you some questions:
- How many UPnP diveces were present in the network?
- Have you encountered problem with missing UDP multicast packet (especially SSDP one)?
Me and Francesco Furfari have discovered such problem with the current implementation on a network with many UPnP devices, in fact we're planing to refactoring part of code which implement UDP communication before releasing the final 1.8.0.
Ciao,
Stefano "Kismet" Lenzi
Hello,
We did not use a big amount of devices in our test network, never more then 6 or so, and never really experienced any problems with missing UDP packets. I do have a remark on the announce messages. A root device doesn't announce itself in the way is described in UPnP Device Architecture (screenshot of page 13: http://users.atlantis.ugent.be/dvrslype/UPnP/upnp.png\). Here you do not perform the second announce message. In this matter we changed this in org.cybergarage.upnp.Device.announce() somewhere around line 1220:
// uuid:device-UUID(::upnp:rootdevice)*
if (isRootDevice() == true) {
String devNT = getNotifyDeviceNT();
String devUSN = getNotifyDeviceUSN();
ssdpReq.setNT(devNT);
ssdpReq.setUSN(devUSN);
ssdpSock.post(ssdpReq);
// ADDED
String devUDN = getUDN();
ssdpReq.setNT(devUDN);
ssdpReq.setUSN(devUDN);
ssdpSock.post(ssdpReq);
}
I currently have lots of stack traces concerning SocketException, SocketTimeoutException and ConnectException. I haven't currently figured out if the cause is in the basedriver. If I find anything, I'll keep in touch.
My current code (where I applied me changes to code i svn'ed yesterday from felix and cyberlink):
http://users.atlantis.ugent.be/dvrslype/UPnP/upnp.rar
gr,
dvrslype
PS: dvrslype is my nickname
I'm researcher at IBCN - INTEC - Ghent University (Belgium)
Hi dvrslype,
All the error SocketException, SocketTimeoutException and ConnectException comes from the CyberLink stack, and they are the same error that we get and we think that due to the many devices on our network we lose some UDP because no thread is free to listen to new messages.
It's worth to notice that not all the exception means an error on the execution of the program in fact they exception arise because the HTTP header Connection field is set to Alive but no Content-Length is provided and we have to wait till the other peer to close the connection in order to gather all the content carried by the HTTP connection.
Let me know if you get any different opinion on that, I'll really appreciate it :)
Ciao,
Stefano "Kismet" Lenzi
P.S.: I have applied all your patches proposed on this thread, I haven't checked the UPnP.rar and I have released a new SNAPSHOT version of the library (see SVN revision 63).
When you say:
"[...] If some device properties aren't filled in (like Serial number or UPC or ...), they appear in the DeviceDescription XML file as <UPC /> which is off course valid XML, but Intel Tools doesn't like it this way, so we made sure all properties were filled in properly. [...]"
Do you mean that you had to changed the XML generation in order to produce XML tag like "<UPC></UPC>" or that you had to fill all the properties manually even if it was missing, with some default value like "N/A", "Unavailable", " " or "null"?
Ciao,
Stefano "Kismet" Lenzi
About the Exceptions: it doesn't seem to trouble the functionality, just didn't know what they meant. I suppose I agree on that HTTP issue, nothing to do about it.
About the XML: I tried to create <UPC></UPC> by doing this in org.cybergarage.xml.Node.output around line 350:
if (value == null || value.length() == 0) {
// No value, so use short notation <node />
ps.println("></" + name + ">");
}
But it still results in <UPC /> in the xml device description.
When I try to fill in "null", <UPC>null</UPC> is shown in the device description:
if (value == null || value.length() == 0) {
// No value, so use short notation <node />
ps.println(">null</" + name + ">");
}
So I guess somekind of optimizer (XML generator) cancels this first trial out.
Not that a big issue I guess, since <UPC /> is valid XML, only some UPnP stacks don't seem to support it.
regards,
dvrslype
Hi dvrslype,
I couldn't find where <tag></tag> is replaced with <tag />, but I don't want to use the <tag>null</tag> notation...
Would you mind to test the latest upnp-stack artifact? It should include all your patches.
And if you find any error or different with your custom version let me know.
Ciao,
Stefano "Kismet" Lenzi
Hello Stefano,
Off course I will test your new stack, where can I get it?
Concerning the XML, I don't know if this is really important, since the produced code is valid XML. Maybe another option is to omit the tag...
bye,
dvrslype
If your using the Felix UPnP Base Driver, and you're compiling the code with Maven you'll automatically get the latest version because Maven looks every time for updates, if you want to be sure you can re-compile the code after a clean be executing the command:
mvn clean install
If you're using cyberlink directly without using Maven you can download the latest version at:
http://cgupnpjava.sourceforge.net/snapshots-repository/org/cybergarage/cyberlink/upnp-stack/1.8.0-SNAPSHOT/upnp-stack-1.8.0-20071001.175529-6.jar
Avoiding to write empty XML could be a solution... But I have to check if it will break some code, and also I have to write it the documentation that the Node.toXMLString() generate XML String in "special" way (it skips tags with no child)
Ciao,
Stefano "Kismet" Lenzi
On first sight, the new binary you gave me does everything I need (i.e. compatibility with Intel UPnP Tools). If there are further problems, I will report them here.
I don't use Felix build directly, I copied the source in my own build system. The current binary you provided me, is this the same as the source I can check out from the sourceforge SVN? I usually update Felix and cybergarage separately.
I have found a new issue caused in the Felix basedriver. I will post it here, should I put it somewhere else (I saw you were on the Felix team to, and I don't like the tracking system...)?
In org.apache.felix.upnp.basedriver.exportGeneralActionListener, after successfull invocation of an Action (Dictionary invoke(Dictionary)), the basedriver tries to extract the values of the outargs from the dictionary and put them in the ArgumentList object of Action. Here arises a problem when an Action has in-out arguments. In the ArgumentList these are treated seperatly (2 Argument objects with the same name, but different argument direction).
When the basedriver wants to set the value for out argument, it does ArgumentList.getArgument(argumentName) and finds the in argument rather then the out argument! So the out argument is never set, resulting in a constant null as value for the out argument.
My proposal for a fix:
on line 123:
[code]arg = al.getArgument(outArg[j]); //can be null, tries getting the argument (which can be wrong)[/code]
replace by:
[code]
arg = null;
for (int n = 0; n < al.size(); n++) {
Argument a = al.getArgument(n);
String aName = a.getName();
if (aName == null || a.isInDirection())
continue;
if (aName.equals(outArg[j]) == true) {
arg = a;
break;
}
}
[/code]
Do you agree on this one?
regards,
dvrslype
Related
Code: code
Hi dvrslype,
The code that you are using the same available on the Cyberlink SVN server.
For all the question and problem related to the Apache Felix UPnP Base Driver, please report them on the felix user mailing list and or on the felix JIRA system, you can find the mention service at:
- http://felix.apache.org/site/mailinglists.html
- JIRA: https://issues.apache.org/jira/browse/FELIX
Thank you!
Ciao,
Stefano "Kismet" Lenzi
P.S.: Please do not stop sending feedbacks!
Hi dvrslype,
Have you found any other issues?
Is everything working now?
Would you mind to open a Bug on the tracker for the bug that you reported?
Ciao,
Stefano "Kismet" Lenzi
I have checked the changes made to the SVN repository and all you requested patches have been applied during revisions 64 and 65.
Please correct me if I'm wrong :)