I have a project along these lines called AMNETD at
http://www.movsoftware.com/developers/amnet/amnet.htm

AMNETD is an application daemon that is used to route nodes within a
serverless ad-hoc environment. It doesn't have the concept of a special
"gate" node to a server, instead every node is a router and when a message
arrives it will attempt to send that message along a direct connection to
the destination. If that direct connection is not possible it will
re-broadcast the message to all of its neighbor nodes. Each node also has a
message store (store-and-forward) which will store messages it is attempting
to send if the destination can't be found. It uses a message receipt system
based on XEP-0184 which it uses to determine when a message should be
removed from the store.

The system was written for a sensor network application but it should route
out messages to the Internet "out-of-the-box". However that's never been
tested.

One thing I like about this system is that it works with all XMPP clients;
they just need to connect to localhost.

If you have any questions about it please email me. The source code is
public domain so feel free to mess with it. 


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Sebastian Schoepke
Sent: Thursday, February 18, 2010 5:35 AM
To: [email protected]
Subject: [mobile] User discovery in mobile ad hoc and infrastructure
networks at the same time (bridging serverless and server mode)

Hello,
I'm new in XMPP. So I've some questions and hope you can give me some tips.
Currently, I'm studying the possibility of applying XMPP for user discovery
in ad hoc and infrastructure networks at the same time.
Some background information of my project: There are two environments, the
infrastructureless serverless ad hoc environment (e.g. conference, train)
and the internet environment. I want to discover users in the ad hoc and in
the internet environment. XMPP clients (e.g. installed on a smartphone)
inside of the adhoc environment communicate directly without the use of any
server. So XEP-0174 appears to be the right solution for it.
If a user wants to discover other users outside of the current adhoc
network, his client must connect to his XMPP "home" server. So he needs a
connection to the public internet. But most of the clients inside of the
adhoc environment will not have any active wireless connection to the public
internet. Thus they cannot connect to their XMPP home server. To realize
this, I need special clients which act as a gate. A gate will have an active
connection to the internet (e.g. through UMTS, WLAN hotspot). Through the
gate the adhoc clients can reach their XMPP server. But the gate shouldn't
act as a simple NAT. Rather, it should act as a kind of proxy between the
adhoc clients and the XMPP server. I've read BOSH as a suitable solution for
this purpose but I don't want the overhead caused by HTTP. Are there any
other solutions?
Furthermore, the gate should merge the client to server connections to one
connection (similar to a vpn tunnel). In mobile environments this could help
to save bandwidth (e.g. through the usage of data compression methods) and
support handover scenarios (for example the adhoc network "travels" by train
and the gate internet connection switch from the local railroad station WLAN
hotspot to UMTS). The gate complement, which resides of the XMPP server,
unwraps/splits the connections. The XMPP server shouldn't note the
difference between direct connected clients and indirect connected clients
over the gate. Do you know about such proxy solutions? The XMPP component
model doesn't seem to be the right solution for my problem because it uses
subdomains. I'd like to partition a XMPP domain. Some users are present in
the adhoc environment and the other ones in the internet environment.
Makes this sense? Any other suggestions for my problem?

Thanks for your time!

Sebastian Schoepke


Reply via email to