Revision history [back]

click to hide/show revision 1
initial version

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)