GPRS comms

[Stelrad Doulton]

Hi all,

I want to be able to "send" data to remote clients over GPRS. I currently
have a solution whereby I am using http polls to check for data periodically
to emulate the push behaviour I want but this seems wasteful.

I am thinking of a hybrid http/tcp but I don't know too much about
networking so I wanted to run it past you guys to see if the idea has legs:

Whenever a RAS connection is established I could set up a connection to a
custom server application on the same box of my web server to announce my
IP. Now when there is data ready for me the custom server application could
"push" an alert out to me (UDP?). At this point I could use my existing
functionality.

Is this a crazy idea? It assumes that once I have established my RAS
connection, my IP address won't changed is this a fair assumption?

Thanks in advance.

 

[Stelrad Doulton]

edit:

I want to be able to "send" data to remote clients

I want to be able to "PUSH" data to remote clients

I am thinking of a hybrid http/tcp

I am thinking of a hybrid of http and some other tcp protocol

 

[Koen Mannaerts]

Hi Stelrad,

Your plan sounds complicated.
Before continuing, consider the following:

1. Designing a new and sound protocol is a daunting task. I'd have a
look at the heaps of fine protocols already existing, and see what is
fit for the purpose. For instance, lots of the open protocols are
managed or designed by the guys at the IETF, people very knowledgeable
in this field.

2. Your current implementation using http polls isn't too bad. When
establishing a long-time connection between remote systems, regular
two-way keepalives are vital. Periodic polls are an easy way to do
this. Exactly the same approach is used when web services drive a
publisher-subscriber pattern; Open Process Control with XML (OPC-XML)
for instance.

3. Not to confuse or scare you, but a protocol I'd definitely look into
is XML Messaging and Presence Protocol (XMPP, aka Jabber). Your app
sounds a lot like instant messaging; as to me Jabber is a good fit for
your problem, and its bandwidth constraint (I know that every byte costs
over GPRS.)
You may need some time for this. Not to program, but rather to page
through the impressive amount of help and technical documentation
available on Jabber. The protocol is immensely flexible, yet you in
particular only need very basic functionality. It may take some effort
to get everything in perspective.
There are a few tutorials on the WWW how to build basic Jabber clients,
and a number of fine Jabber servers can be freely downloaded.

Koen.

 

[Stelrad Doulton]

Hi Koen,

Thanks for the post. Most informative.

Since my origonal post I have been thinking it over and I was coming to the
conclusion that the way to go was to utilise the TcpClient and TcpListener
classes to implement the client-server architecture. As I am only after file
transfers I had assummed that I could just write a very basic protocol to
handle this. In fact the below (from a Jabber tutorial) sums up my thinking
pretty well

A Jabber session is really just pairs of full duplexed sockets-one at the
Jabber server for each client, one at each of the clients

ie I had been thinking of something like jabber (according to this
definition) but without the XML!

I had actually been planning on sending a periodical "NOOP" to ensure the
channel was still valid. Is this what you are referring to with your
keep-alive comment? Is there a TCP timeout that I will have to bear in mind?

As you say there is a lot on Jabber out there so I have some reading to do
but it looks very interesting.

Hi Stelrad,

Your plan sounds complicated.
Before continuing, consider the following:

1. Designing a new and sound protocol is a daunting task. I'd have a
look at the heaps of fine protocols already existing, and see what is fit
for the purpose. For instance, lots of the open protocols are managed or
designed by the guys at the IETF, people very knowledgeable in this field.

2. Your current implementation using http polls isn't too bad. When
establishing a long-time connection between remote systems, regular
two-way keepalives are vital. Periodic polls are an easy way to do this.
Exactly the same approach is used when web services drive a
publisher-subscriber pattern; Open Process Control with XML (OPC-XML) for
instance.

3. Not to confuse or scare you, but a protocol I'd definitely look into is
XML Messaging and Presence Protocol (XMPP, aka Jabber). Your app sounds a
lot like instant messaging; as to me Jabber is a good fit for your
problem, and its bandwidth constraint (I know that every byte costs over
GPRS.)
You may need some time for this. Not to program, but rather to page
through the impressive amount of help and technical documentation
available on Jabber. The protocol is immensely flexible, yet you in
particular only need very basic functionality. It may take some effort to
get everything in perspective.
There are a few tutorials on the WWW how to build basic Jabber clients,
and a number of fine Jabber servers can be freely downloaded.

Koen.

--
Notice: Remove all packaging [from e-mail address] before use.

Hi all,

I want to be able to "send" data to remote clients over GPRS. I currently
have a solution whereby I am using http polls to check for data
periodically to emulate the push behaviour I want but this seems
wasteful.

I am thinking of a hybrid http/tcp but I don't know too much about
networking so I wanted to run it past you guys to see if the idea has
legs:

Whenever a RAS connection is established I could set up a connection to a
custom server application on the same box of my web server to announce my
IP. Now when there is data ready for me the custom server application
could "push" an alert out to me (UDP?). At this point I could use my
existing functionality.

Is this a crazy idea? It assumes that once I have established my RAS
connection, my IP address won't changed is this a fair assumption?

Thanks in advance.

 

[Koen Mannaerts]

Lifechecks are typically done on the application layer. You're free to
use whatever timeout you think is appropriate. I'm not sure but I
believe Jabber applies one bidirectional lifecheck per minute.

Koen.

Hi Koen,

Thanks for the post. Most informative.

Since my origonal post I have been thinking it over and I was coming to the
conclusion that the way to go was to utilise the TcpClient and TcpListener
classes to implement the client-server architecture. As I am only after file
transfers I had assummed that I could just write a very basic protocol to
handle this. In fact the below (from a Jabber tutorial) sums up my thinking
pretty well

A Jabber session is really just pairs of full duplexed sockets-one at the
Jabber server for each client, one at each of the clients

ie I had been thinking of something like jabber (according to this
definition) but without the XML!

I had actually been planning on sending a periodical "NOOP" to ensure the
channel was still valid. Is this what you are referring to with your
keep-alive comment? Is there a TCP timeout that I will have to bear in mind?

As you say there is a lot on Jabber out there so I have some reading to do
but it looks very interesting.

Hi Stelrad,

Your plan sounds complicated.
Before continuing, consider the following:

1. Designing a new and sound protocol is a daunting task. I'd have a
look at the heaps of fine protocols already existing, and see what is fit
for the purpose. For instance, lots of the open protocols are managed or
designed by the guys at the IETF, people very knowledgeable in this field.

2. Your current implementation using http polls isn't too bad. When
establishing a long-time connection between remote systems, regular
two-way keepalives are vital. Periodic polls are an easy way to do this.
Exactly the same approach is used when web services drive a
publisher-subscriber pattern; Open Process Control with XML (OPC-XML) for
instance.

3. Not to confuse or scare you, but a protocol I'd definitely look into is
XML Messaging and Presence Protocol (XMPP, aka Jabber). Your app sounds a
lot like instant messaging; as to me Jabber is a good fit for your
problem, and its bandwidth constraint (I know that every byte costs over
GPRS.)
You may need some time for this. Not to program, but rather to page
through the impressive amount of help and technical documentation
available on Jabber. The protocol is immensely flexible, yet you in
particular only need very basic functionality. It may take some effort to
get everything in perspective.
There are a few tutorials on the WWW how to build basic Jabber clients,
and a number of fine Jabber servers can be freely downloaded.

Koen.

--
Notice: Remove all packaging [from e-mail address] before use.

Hi all,

I want to be able to "send" data to remote clients over GPRS. I currently
have a solution whereby I am using http polls to check for data
periodically to emulate the push behaviour I want but this seems
wasteful.

I am thinking of a hybrid http/tcp but I don't know too much about
networking so I wanted to run it past you guys to see if the idea has
legs:

Whenever a RAS connection is established I could set up a connection to a
custom server application on the same box of my web server to announce my
IP. Now when there is data ready for me the custom server application
could "push" an alert out to me (UDP?). At this point I could use my
existing functionality.

Is this a crazy idea? It assumes that once I have established my RAS
connection, my IP address won't changed is this a fair assumption?

Thanks in advance.