03-25-2010 06:50 AM
Hi all,
I'm trying to make an application who sends udp packets to the same IP address, but through different networks, at example wifi, EDGE,UMTS or the classic GPRS. The JApp documentation explains that "To open a datagram connection on a non-GPRS network, specify the source port number, including the trailing slash mark.
For example, the address for a CDMA network connection would be udp://121.0.0.0:2332;6343/."
Well, anyone could confirmate it's true? Changing a port number would really specify the wireless transport protocol?I'm not sure, cause there's also the interface parameter, but it can be used only for wifi...
Another doubt: can a simulator like the 9000 BB Bold test this feature?
Every information would be apprecciate,
Thanks.
03-25-2010 07:47 AM
You can specify the transport only in as much as selecting between the cellular interface and the Wi-Fi interface by appending ";interface=wifi" to the Connector.open() connection URL parameter to select the Wi-Fi interface (if you don't append that parameter, it will select the cellular interface and will use the Carrier UDP which completely bypasses RIM network infrastructure).
03-25-2010 07:48 AM - last edited on 03-25-2010 07:56 AM
P.S. Handheld simulator can test this feature. Just pick one where UDP works (e.g., Curve 8900 from JDE v4.6.1).
03-26-2010 06:12 PM
Thanks for the reply,
In the API references no other interfaces are mentioned, so I hoped it would be possible to select other network interfaces...So, actually for udp or tcp applications, the avalaible interfaces are only the classic GPRS and wifi?
Because I want to develop an application which use EVERY avalaible interface supported in the last BB model, to send packets via wireless, so the interface param is really a bottleneck...no one could help? Maybe an alternative (and compatible) method different to Connector.open or something similar...
Thanks for the replies.
03-27-2010 05:57 AM
The tunnelling of UDP via the BlackBerry network infrastructure is not exposed to third-party applications (it may be this is not even supported at all). This means that there appears to be no way to send or receive UDP via BIS-B and MDS transports, unless you tunnel UDP via TCP, which mostly defeats the purpose of using UDP in the first place.
03-27-2010 05:59 AM - last edited on 03-27-2010 06:00 AM
P.S. TCP is supported by the MDS, BIS-B, WAP 2.0 TCP, Carrier TCP, and Wi-Fi TCP transports (basically, all of the transports exposed to third-party applications except for the WAP 1.x transport).
03-27-2010 07:05 AM
TCP incapsulation would be a good idea, I think, but what about performances?The application i was planningwould've been propedeutic for the implementation of a multi homing VoIP a client. So, i think TCP incapsulation would be too much expensive for that...
Thanks for the replies.
03-27-2010 09:06 AM
However, by default, the datagram connection is based on the infrastructure network of the carrier, not the MDS. Well, if if we admit that we've the possibility to use different interfaces (provided by the carrier) with a BB with multiple NICs, Can I force a packet to be sent to one of these interfaces? At example if I specify a GPRS apn in the connector.open, i think I'm routing the packet through GPRS network (right?), but what about, at example, an UMTS or a CDMA network?
Think that I'm always expecting that the carrier could support different network interfaces, regardless the implementation...
03-27-2010 12:04 PM - last edited on 03-27-2010 12:05 PM
If you refer to CDMA, UMTS, GRPS/EDGE, UMA as "network interfaces", then all of them are transparently supported. If you don't specify ";interface=wifi" when creating a DatagramConnection, then the UDP traffic of this connection will go via the current "network interface" though which the device is exchanging data with the carrier. I don't know of a way to force a particular "interface" as this would make no sense -- at the application level (i.e., above the radio network stack), a device can be only connected to the carrier via one such "interface" at a time.
03-27-2010 12:45 PM
I know: I'm just working in group to an architecture which can send every single packet to a different interface, implementing balancing and performance policies...the difficult is that, how u said, at application level I don't know what to do to force the changement of interface. Probably, I would need to work at level network or transport, but APIs can't help...any suggestions
?