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?

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

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.
SubscriberProxy if you are subscribing from a remote system.
threadyAuthor Commented:
What would the SubscriberProxy entail?
Exploring SharePoint 2016

Explore SharePoint 2016, the web-based, collaborative platform that integrates with Microsoft Office to provide intranets, secure document management, and collaboration so you can develop your online and offline capabilities.

I'm thinking again .. see my  thoughts attached

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
threadyAuthor Commented:
Awesome!  Just got this.  Looking over it all.  Wow thanks man!  :)
threadyAuthor Commented:
Yet another one for you to see if interested  :)
threadyAuthor Commented:
Which program did you use for the UML?
I had a trial version of Visual Studio 2010 running - used the architectural project and grabbed screen
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?
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 ...
Correction: RS has a set of Listeners not just one. So each listerner can be listening on a different port/protocol/family
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!  :)
>>  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

- 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) {
threadyAuthor Commented:
Would you recommend NotificationService be a Singleton?
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.
threadyAuthor Commented:
Ah- singleton's are usually loaded dynamically?  (not statically linked?)

When you say register/unregister- you mean for events?
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");
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.