1

what is the role of session port in alljoyn

asked 2014-06-24 01:42:15 -0700

qieman gravatar image

updated 2014-06-26 19:56:08 -0700

In TCP/UDP, one device has only one ip, and port is used to distinguish different services. However, in alljoyn, every service has a unique well-known name, so why we need session port here? In a sample service code, BusAttachment requests a name, and bind to a session port, it seems that the name has already identify the BusAttachment, the session port is meaningless. I thought one busAttachment can bind to only one well-known name and one sessionPort thus I thought sessionPort is redundant, but today I read the sample code RawService and I know I was wrong. In this sample a busAttachment requests 2 different well-known names and bind to 2 different sessionPorts. Now I am more confused about well-known name and sessionPort. The methond bindSessionPort take no argument of well known name nor the SessionPortListener.acceptSessionJoiner callback, so if the busAttachment request 2 different names, How does it know which name the client want to join by calling joinSession?

edit retag flag offensive close merge delete

3 answers

Sort by » oldest newest most voted
2

answered 2014-07-10 17:06:30 -0700

Jehan gravatar image

In TCP/UDP, one device has only one IP address. The AllJoyn equivalent is one BusAttachment has one unique name. In TCP/UDP, one device can have multiple hostnames and so in AllJoyn, one BusAttachment can have multiple well-known names. Then the TCP/UDP port is like AllJoyn session port.

And like for TCP/UDP where the hostname is only used to find the IP address, in AllJoyn, the well-known names is only used to find the unique names (well, not quite, but it's a good enough approximation for our purpose). When a TCP connection is being established, the names is irrelevant. So it is for AllJoyn.

Then the session ID is like the socket descriptor in TCP/UDP.

Now in the TCP world, some application (e.g. web server) knows about the hostname, but that's because the higher level protocols (e.g. HTTP) also put the hostname inside the request (e.g. the Host header). But that's like passing a MsgArg with the well-known name in it. At the TCP level, only the port can be used to distinguish between different applications (e.g. HTTP/80 vs Telnet/23) or different "settings" in an application (HTTP/80 vs HTTPS/443).

In my app, I use the session port to return slightly different responses to otherwise identical requests. In a TCP/UDP world, it would be like I return either the full/PC-edition web pages or the more limited/light/mobile-edition of the same pages based on the port number. (Web servers nowadays actually use the User-Agent header but again, that's at the higher level protocol, i.e. it would require an extra MsgArg to emulate that)

edit flag offensive delete publish link more

Comments

Nice elaboration! Thanks a lot!

qieman ( 2014-08-25 23:02:55 -0700 )edit
0

answered 2014-06-24 02:04:32 -0700

alphaemmeo gravatar image

Hi qieman, the AllJoyn session ports are NOT tied to networking ports. Reading this documentation of sure you will understand the several session feature: https://allseenalliance.org/sessions

best regards

edit flag offensive delete publish link more

Comments

Thanks. But I'am still confused now.

qieman ( 2014-06-26 20:00:31 -0700 )edit
0

answered 2014-06-26 12:03:27 -0700

mattpho gravatar image

I think what qieman mentioned is the "listening" port passed to BindSerrionPort() on the device which forces a client to know both the device WKN and the listening port (instead of just the WKN) before connecting to a device. Is it possible for AllJoyn to define a default listening port number so that client can hard code it? Also is there a valid range of "listening" port number defined as in IP port numbers?

edit flag offensive delete publish link more

Comments

Thanks. I thought one busAttachment can bind to only one well-known name and one sessionPort thus I thought sessionPort is redundant, but today I read the sample code RawService and I know I was wrong. In this sample a busAttachment requests 2 different well-known names and bind to 2 different sessionPorts. Now I am more confused about well-known name and sessionPort. The methond bindSessionPort take no argument of well known name nor the SessionPortListener.acceptSessionJoiner callback, so if the busAttachment request 2 different names, How does it know which name the client want to join by calling joinSession?

qieman ( 2014-06-26 20:02:05 -0700 )edit

Maybe I'm falling in error, but I understood that a well-known name is tied at the busAttachment and the sessionPorts at the session. Then a busAttachment can live in different sessions.

alphaemmeo ( 2014-06-27 06:53:55 -0700 )edit

Qieman, could you please point me to the RawService sample? I thought a single BusAttachment can only have one WKN but I might be wrong. I'd like to play with the sample. Thank you Matt

mattpho ( 2014-06-27 10:19:59 -0700 )edit

To mattpho, the sample is a java sample in "AllJoyn SDK 14.02.00 - Android (release)". https://www.alljoyn.org/docs-and-downloads

qieman ( 2014-06-29 20:36:59 -0700 )edit
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2014-06-24 01:42:15 -0700

Seen: 796 times

Last updated: Jul 10 '14