thready
asked on
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
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
SubscriberProxy if you are subscribing from a remote system.
ASKER
What would the SubscriberProxy entail?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Awesome! Just got this. Looking over it all. Wow thanks man! :)
ASKER
Yet another one for you to see if interested :)
https://www.experts-exchange.com/questions/27664404/Bidirectional-nature-of-sockets.html
https://www.experts-exchange.com/questions/27664404/Bidirectional-nature-of-sockets.html
ASKER
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
ASKER
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Correction: RS has a set of Listeners not just one. So each listerner can be listening on a different port/protocol/family
ASKER
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
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) {
}
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) {
}
ASKER
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/Service s 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.
Its also possible to have a Kernel/Application/Service
ASKER
Ah- singleton's are usually loaded dynamically? (not statically linked?)
When you say register/unregister- you mean for events?
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(st ring 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<Notifi cationServ ice>("noti fications" );
LogService* log = gKernel.findService<LogSer vice>("log ");
NotificationService gNotifService;
Register/UnRegiser were meant for the Service manager. E.g.
Kernel::registerService(st
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<Notifi
LogService* log = gKernel.findService<LogSer
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.