Somebody know about possibility to establish in different threads of J2ME Midlet 2-3 parallel HTTP connections. I's looks possible but works unstable. Maybe somebody have more information about topic.
It is certainly worth a try and I believe this will work on some good phones but this is typically something that the JSR-118 Test Conformance Kit doesn't test for (as far as I can remember) so it could very possibly fail on some phones too.
Related
I found out about OpenWebRTC and was wondering if there was a way to implement it in the suckless surf browser.
Does anyone know if this is possible and how I would go about it?
I wouldn't use OpenWebRTC, development has stopped and you will probably hit bugs. WebRTC has had some pretty big changes since development has stopped (PlanB -> Unified Plan) and mDNS candidates.
GStreamer itself now has webrtcbin. There are also WebRTC implementations (webrtc.org, aiortc, pion) that can do media!
I would build the WebRTC integration out of process. You could write some IPC and let a 'WebRTC implementation' talk over a socket and exchange SDPs back and forth. I don't know surf's code that well to know how possible that is though.
I have a c++ application running on the Raspberry Pi that uses the bluez d-bus api. It supports multiple sensors from different vendors but for the most part adding new sensors has been fairly straight forward once I'd got the first one going. Once connected I'm not really using anything too exotic, just "StartNotify", "StopNotify", "ReadValue", and "WriteValue". Anyway, recently I've had problems adding a couple of new sensors. Both use larger packet sizes so using a packet sniffer I can see the sensors negotiating larger MTU. For whatever reason though after the negotiation I can read larger value characteristics but can't get notifications enabled (or received anyway). Trying different approaches with bluetoothctl I found that using "acquire-notify" seems to solve the problem. I also notice that the new "acquire" commands return the MTU so maybe that has something to do with it. Going back to the sensors I already support I've also found that replacing "StartNotify" with "AcquireNotify" seems to work with them as well. So my delimma is whether to use "AcquireNotify" for all sensors (keeping my code a lot cleaner) or just the new ones that give me an issue.
I haven't really found any in-depth documentation on the new "acquire" interfaces unfortunately. To someone without a lot of bluez history it's not at all clear what the ramifications of using them vs the original interfaces are. So my questions are twofold -
Is there any reason not to use "AcquireNotify"/"ReleaseNotify" for
all sensors (even older ones that use old/lower MTU)?
When using "AcquireNotify" does it matter if you use
"ReadValue"/"WriteValue" on other characteristics, or should I be
using "AcquireRead"/"AcquireWrite"?
Any info greatly appreciated, Thanks!
AcquireNotify returns a file descriptor that you can poll and read and notifications don't go through d-bus. with StartNotify you read the notification value from d-bus. you'll be able to achieve better performance with file descriptors (and without d-bus) if you're sending a lot of data in GATT notifications.
AcquireNotify/AcquireWrite are relatively new APIs and they have some stability issues (bluetoothd can terminate because of SIGPIPE). there are some patches to bluez 5.50 in their repositories that improve it.
Figured I'd follow up for anyone else seeing similar behavior. Oddly, after trying all kinds of permutations sending commands using bluetoothctl I found a way to get it working without using the notify-acquire api's. Randomly I found that if I enabled notifications via "notify on", then did the sensor vendor's recommended write command sequence to get the sensor to start sending data nothing happened. But if I did all that and then simply used "select characteristic" to go back to the notify characteristic I'd enabled it would start sending data. Not sure why. At any rate once I'd fully integrated the sensors into my application they actually worked without requiring anything extra. Not sure why exactly since my code is based directly on the bluetoothctl source but regardless it seems to work (so far anyway)...
i am newbie to Linux platform, i am working on java technology.
what i have to do is : Having a program that running on mobile devices,that sends some data to my Linux machine, now i have to create a program in java that
listen to a particular port.
access data comes on that port(which is sending by mobile device)
save that data to the database.
response back to the mobile device.
i.e. i would make my Linux system as server that can listen from many clients(mobile devices), but not getting how to configure this environment... :(
i used cent OS 5.4 and
installed jdk1.6.0_24
any help would be appreciated.....
thanx in advance!
khushi
One of Java's greatest strengths is that you can pretty much ignore the host operating system as long as you stick to core Java features. In the case you're describing, you should be able to accomplish everything by simply using the standard Java networking APIs and either the JDBC to access an existing, external database or you could choose any number of embedded Java databases such as Derby. For your stated use case, that you'll be running the application on Linux is pretty much irrelevant (which should be good news... you don't need to learn a whole operating system in addition to writing your app ;-).
Here's a nice client/server tutorial, in that it is broken into steps, and adds each new concept in another step.
Here's another client/server tutorial with much more detail.
I would write it to accept one connection at a time. Once that works, I would study the new(ish) java.lang.concurrent classes, in particular the ExecutorService, as a way of managing the worker bee handling each connection. Then change your program to handle multiple connections using those classes. Breaking it up in two steps like that will be a lot easier.
I am currently working on a robotics simulation environment.
Robots, that can interact with he virtual wold can be controlled/monitored via a network connection.
For the whole network communication (and of course other things e.g. Threads) we use the ACE library.
The problem I have now is that it seems to me that the asynchronous UDP part is broken.
When running the test program "test_udp_proactor -h localhost -p 55555" that comes with ACE I will always get the errorcode 89 (Destination address required).
So far this is what I tried, but nothing helped:
recompiling newer/different versions of ACE
modifying the code of test_udp_proactor, recreating a similar program
changing the environment (different PC with 32bit CPU and Ubuntu 9.10)
When using synchronous methods everything works just fine, so there is no error with the network hardware/software.
I searched google and this site for hours/days now and it seems that nobody else has this problem! At least I can't find it.
I am really frustrated now, because as far as I understand it, ACE is really mature and reliable. Though some people are very fond of the design of it.
It is used in the aerospace community, where reliability and Real-Time aspects are a must!
I can't believe ACE doesn't support asynch. UDP communication and/or nobody else found that out.
Can somebody run a simple test for me with test_udp_proactor to verify this behavior?
We have to use a real-time capable system, so windows is not an option...
Any other hints and/or tips, preferably from the ACE-gurus ? :-)
Thank you very much
Try looking at the problem at a system call level. Use strace to see what system calls and values are being sent to the kernel and what error codes those system calls are returning.
You may find your problem quickly.
I am a .NET programmer who needs to port one good Desktop OTP system already at work to be used into cell phones. As far I know J2ME is the correct answer to do it. I'll appreciate any good advice about IDE, first steps, books or any other information.
Well, Eclipse IDE have good J2ME support, or so I've heard.
For api, read the javadocs:
http://java.sun.com/javame/reference/apis.jsp
You'll have to figure out which device you want to target, and grab its emulator.
Then, proceed making a hello world app with the aid of tutorials.
I would give NetBeans a try as well. Eclipse and NetBeans are very similar, but the differences can be night and day depending on your personal preferences. NetBeans also has great J2ME project support, and it is plug and play for any emulator of a device you may need to target, though I recommend sticking to the default or SonyEricsson's. Motorola's was always buggy and never reflected the device at all, and Nokia's was always sloooow.
Also, there are a ton of devices out there. Before you jump head first into this you should define a scope of exactly which devices you will need to target. This will have a huge impact on scheduling as porting is no small task.
Finally, just get your hands on the actual devices you need to target. Emulator is a good way to start, but there are always so many nuances and problems that pop up once you throw the app on the device that it's best to have your target devices from day one.