TPP thread on client

[Zeno Loco]

In my client application I'm thinking to create a backgroundv thread
waiting on a port for TCP communication with a server.
Does someone have experienced this solution?
Is it too expensive for "standard" mobile devices?
Do you have any suggestion about it?

Thanks

Zeno

 

[Daniel Moth]

That is fine. It is typical to have a dedicated thread blocking while
waiting for incoming connections. You could also use the BeginXX/EndXX async
pattern built into many framework classes.

Basically, socket programming is pretty much the same between both platforms
so you should be able to use samples from one on the other...

Cheers
Daniel

 

[Lonifasiko]

Would be possible then using this approach that server side could
"trigger" something into a TCP channel in a concrete port number so
that client application could be noticed? Maybe for important
notifications that client must know.

Thanks very much in advance.

 

[Daniel Moth]

Not entirely sure I know what you mean but I think the answer is yes. Like I
said general rule of thumb, if you can do it with 2 PCs (at the socket
level), then you can do it with PC and device (assuming device is also
always connected, of course).

Cheers
Daniel

 

[Zeno Loco]

.... and thinking about this solution :

.. it is possible to know if a certain port is already used by another
thread/application?
.. it is possibe to avoid other application to use your port ?
.. the mobile device will slow down whith that thread (I'm thinking
async threading as you suggest)

Thanks

Zeno

 

[Lonifasiko]

My purpose would be to notify a PDA client of a critical event occured
in server-side. As you say, I'm afraid an "always connected" scenario
is needed.

Because using a timer that listens for example each 5 minutes in a TCP
channel and in a specified port number is almost the same as making a
synchronization with Merge Replication, isn't it?

I would like to hear your opinions.

Thanks very much.

 

[Daniel Moth]

Rather than think about it, I suggest pulling a ready made example, there
are many on the web/msdn or just trying it out yourself.

Normal port rules apply. If you try to use one (open/listen) that is already
in use you'll get an exception.

I said async pattern not "asynch threading". Look up those BeingXXX methods.
I can't imagine noticeable perf differences between that and a dedicated
thread (since the latter will mostly be blocked), but I haven't measured.

Cheers
Daniel

 

[Daniel Moth]

If you are not permanently connected then you should be thinking the other
way round. Device initiates the connection to PC and checks the status or
whatever else you want to do.

(please start new threads for new questions, rather than hijacking existing
ones)

Cheers
Daniel

 

[Zeno Loco]

Thanks Daniel

I had no notice about async pattern, I'll have a look

Zeno

 

[Paul G. Tobey [eMVP]]

If the device really is 'always connected', it should connect to a TCP port
on the PC and ask for notifications. The PC server should keep a list of
open connections to its port and, when the indicated event occurs, send a
suitable message to all of the connectors.

If message delivery doesn't need to be guaranteed, you could use a UDP
multicast group to send a single message to everyone who cares, but there's
no guarantee that all clients will receive it.

There are many trade-offs.
Paul T.