Widcomm implementation

8 views
Skip to first unread message

Mina Shokry

unread,
Dec 8, 2007, 5:35:37 AM12/8/07
to bluecove-...@googlegroups.com
Dear Vlad,
I got the permission to send the implementation to you
but note that:
1 - it is not a complete implementation, it just contains functions that we needed.
2 - it is not tested well, so it is surely (I don't say may but surely) contains bugs.
3 - As you surely got Widcomm APIs aren't well documented. so, our implementation might contain wrong uses of APIs (but I don't think so).
4 - as I remember, it can accept multiple connections.
5 - the project was to be called EJIBT82 (keeping this name is the only constrain I got with the permission to publish this code).

Me who wrote all of code and you can contact me personally for anything related to this code.

as I knew my previous company will also try to contact you to work all together.
EJIBT82.zip

Vlad Skarzhevskyy

unread,
Dec 8, 2007, 11:19:34 AM12/8/07
to bluecove-...@googlegroups.com
Hi Mina
It is very good that your company decided to support open source and
contribute to community.
Unfortunately the code I see in your e-mail is missing some interesting parts.
- nativeOpenCilent is missing
- nativeOpenServer is missing

So I regret that this helps no way in improving missing multiple
connections for service functionality in BlueCove.

I see that you are using aggressively AttachCurrentThread in native
callbacks. What is your experience with this approach. How reliable
was established connection?

Regards,
Vlad

Mina Shokry

unread,
Dec 8, 2007, 2:11:51 PM12/8/07
to bluecove-...@googlegroups.com
hi Vlad,
I reviewed the code I sent to you and ensured that it contains these methods, they are in the file named "com_eg_pulse_jsr82_StreamConnectionImpl.cpp". for your convenience I attached it again.

for calling AttachCurrentThread:
Widcomm APIs structure looks like JSR82 in many places, for example to start device discovery we call a method and a callback occurs for each found device.
so, a normal thinking is to make JSR82 method DiscoveryAgent.startInquiry() call Widcomm CBtIf::StartInquiry() and when callback occurs make Widcomm CBtIf::OnDeviceResponded call JSR82 DiscoveryListener.deviceDiscovered().
because Widcomm callback occurs in a different thread and also JSR82 should occur in another thread we can make CBtIf::OnDeviceResponded call DiscoveryListener.deviceDiscovered() directly.

but only a JVM thread can deal with JNI references (Native threads can't) and Widcomm callbacks are in native threads, so I found the solution is to attach the Widcomm native callback thread to the JVM to be able to call Java method DiscoveryListener.deviceDiscovered().

I don't think calling AttachCurrentThread() a lot will make problems if I attach and detach correctly. and it didn't cause problems in our tests but as I told you before, this implementation isn't well tested.

finally don't worry about me and the previous company, I left them for other reasons and me who told them that BlueCove supports Widcomm.
and I may be back to work with them again soon as I didn't find a new job yet and they need my work.
bye.
com_eg_pulse_jsr82_StreamConnectionImpl.cpp

Vlad Skarzhevskyy

unread,
Dec 8, 2007, 11:53:46 PM12/8/07
to bluecove-...@googlegroups.com
Ups sorry.
Apparently you do the same things with services as bluecove does.
There are no way your service can accept multiple connections. There
are only one function OnDataReceived per service and it has no
selector and so only one connection can be handled.

The only way I see this can be solved is that each acceptAndOpen()
will create new CRfCommPort and call OpenServer(). The will close
server while keeping data coming in.

What I do differently is I'm calling OpenServer for each
acceptAndOpen(). But you do it once you created a service. Does your
server respond to second connection after first is closed?

BTW I know that "avetana" does not implement multiple connections at
the same time. Also all questions on the subject to WIDCOMM are
silently not answered. Probably they need to change API to handle
this. I don't even know if this OK by RFCOMM standard. I only know
that this works in MS and OS X implementation.

Regards,
Vlad

Mina Shokry

unread,
Dec 9, 2007, 5:49:25 AM12/9/07
to bluecove-...@googlegroups.com
Hello Vlad,
sorry, I can't answer your question now because as I told you the implementation isn't well tested, we just tested it with what we needed and we only needed one connection.
also, I can't try it now because I don't have access to a Windows machine. the only computer I have now is my laptop which is running with Ubuntu.

ok, may we start talking about how the BlueZ version will be implemented?

Regards,
Mina

Vlad Skarzhevskyy

unread,
Dec 9, 2007, 4:37:03 PM12/9/07
to bluecove-...@googlegroups.com
Mina
Thanks anyway. It got me thinking and now I implemented support for
multiple connection in RFCOMM server. Code in SVN and in new build as
of tonight.
Regards,
Vlad
Reply all
Reply to author
Forward
0 new messages