sockets, multicast and bluetooth

Hi Experts,

Is it feasible and a good idea to create a TCP Server that would allow incoming sockets to be treated as observers of notifications, where these connections happen over bluetooth and/or over tcp/ip?  I would somehow have to create sockets that don't distinguish how the connection was made- is this how it's done?  Or does accepting both types of connections require 2 servers within the same application?

Thanks!
Mike
LVL 1
threadyAsked:
Who is Participating?
 
ambienceConnect With a Mentor Commented:
I'm thinking again .. see my  thoughts attached
Untitled.png
0
 
ambienceCommented:
As far as I know there would be a need to abstract different addressing types, which BTW is also a case when you want IPv6. Luckily, on Windows, the same Winsock API is used for Bluetooth communication though with different addressing structures. See this http://msdn.microsoft.com/en-us/library/windows/desktop/aa362901%28v=vs.85%29.aspx.

I haven't done any bluetooth programming with sockets therefore I'm not sure whether you need to have two server sockets bound to different addresses each listening for incoming connections - but I am 99% thats the way it would be.

>> Is it feasible and a good idea to create a TCP Server that would allow incoming sockets to be treated as observers of notifications, where these connections happen over bluetooth and/or over tcp/ip?

Not sure I fully understood that.

Perhaps it would be better to have a say Proxy class that observes notifictaions and manages bidirectional communication. The proxy gets created for every incoming connection and owns the connection. There would be a list of proxies at any time and when a connection drops the proxy gets deleted. A proxy is also logical abstraction on a raw connection because you would most definitely want to add logging there, no? Sockets with logging becomes a bit esoteric IMHO.
0
 
ambienceCommented:
SubscriberProxy if you are subscribing from a remote system.
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
threadyAuthor Commented:
What would the SubscriberProxy entail?
0
 
threadyAuthor Commented:
Awesome!  Just got this.  Looking over it all.  Wow thanks man!  :)
0
 
threadyAuthor Commented:
Yet another one for you to see if interested  :)
http://www.experts-exchange.com/Programming/Languages/CPP/Q_27664404.html
0
 
threadyAuthor Commented:
Which program did you use for the UML?
0
 
ambienceCommented:
I had a trial version of Visual Studio 2010 running - used the architectural project and grabbed screen
0
 
threadyAuthor Commented:
I've been looking and looking again at your architecture.  I'm new to UML and I just don't get it.  Would you mind saying a few words about the flow of objects through this scheme?
0
 
ambienceConnect With a Mentor Commented:
Let me try :)

NotificationService is the main object, this is the object that you'd use to raise notifications or get notifications from.

Internally it has a NotificationCenter which is kind of a registry of Observers (almost similar to POCO NotifcationCenter and certainly you can use it here). The NS uses the NC to manage local notifications etc.

The other main object is RemotingService, whose job is to manage a list of networked publishers/subscribers. So whenever a notification is raised the NS hands over to the RS. Also, when RS receives a notification it can

- either pass it to NC so that local entities are notified (RS can keep a reference of NC for that)
- pass upwards to NS and then NS can use NC (upto you how you design)

RS also has EndpontListerner whose job is to listen for connections and pass RS an Endpoint

The SubsriberProxy is the object that own an endpoint and RS creates a proxy and passes it the EP. SP does the job of serializing and deserializing notification objects into byte arrays. RS pass SP the notif and SP does the serialization. You can modify the design here and if the need is to send the same notif to every SP then the serialization can be done by the RS and pass same bytes array to all SP.

The last two entities comprise the serialization framework. Serializer is the abstract class (interface). A binary serializer would convert notif into your own binary format. You can later have say a GoogleProcotolBuffersSerializer that uses ProtBuffers for cross platform serialization or even XmlSerializer. Basically, a serializer is pluggable.

I hope that helps .. let me know if you have questions ...
0
 
ambienceCommented:
Correction: RS has a set of Listeners not just one. So each listerner can be listening on a different port/protocol/family
0
 
threadyAuthor Commented:
I see!  I think my SubscriberProxy could be the same object as my abstract base class for Notification objects.  Correct?  Thanks a lot for your help!  :)
0
 
ambienceCommented:
>>  I think my SubscriberProxy could be the same object as my abstract base class for Notification objects.

Why do you say that? In the diagram i didnt inherit Notification from anything but you are free to create a hierarchy if you want like

Notification
- UpdateNotification
- RefreshNotification

A Notification is just a notification. It can have a Notification code like UPDATE and it can have extra attributes or a list of key value pairs like an Hashtable. You can call it an Event or a Message if you prefer. If there is going to be a Request/Response sort of scenario then perhaps its better to call it Message (RequestMessage, ResponseMessage).

A Proxy on the other hand is an object that sends and receives Notifications. It can have a method say

void notify(const Notification& n) {
}
0
 
threadyAuthor Commented:
Would you recommend NotificationService be a Singleton?
0
 
ambienceCommented:
its more of a preferences decision. It can be a singleton and thereby no need to keep the reference saved inside the children.

Its also possible to have a Kernel/Application/Services object and have it maintain the lifetime of services as well as provide means to locate, register and unregister. That object can itself be a singleton or even statically linked.
0
 
threadyAuthor Commented:
Ah- singleton's are usually loaded dynamically?  (not statically linked?)

When you say register/unregister- you mean for events?
0
 
ambienceCommented:
no not saying anything about singleton's life-cycle. I was referring to just a global variable say

NotificationService gNotifService;

Register/UnRegiser were meant for the Service manager. E.g.

Kernel::registerService(string moniker, ServiceBase* service)
template<class T>
T findService(string moniker);

-----

In a distributed or pluggable architecture different modules can start and proffer services that may be used by other parts.  Just for idea:

NotificationService* ns = gKernel.findService<NotificationService>("notifications");
LogService* log = gKernel.findService<LogService>("log");
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.