On 8/5/07, Ben Hood <[EMAIL PROTECTED]> wrote: > > Leandro, > > > Thanks for your help. Reading my last post again I think I wasn't clear > > enough. > > That's OK, it's part of thinking about the problem and working out the > best solution. > > > My server will handle TWO different types of clients: > > > > 1) small network devices (via UDP) > > 2) desktop applications (possibly using hessian) > > So small network devices are broadcasting events to mulitple clients? > If so, are the desktop clients on the same subnet as the small > devices? In that case you could bypass the server and multicast > directly to the desktops. If not, you will have to use the server > effectively as a relay.
Yes, I have to use the server to centralize access and perform other functions. > > > The server has to publish the events created on the network enabled > devices > > to all desktop clients that subscribed to the correct type of event. > > > > I guess you thought that I was trying to use hessian for #1, not #2. > > I never used hessian before. I would be really nice to have a > > small/efficient protocol handler to send and receive messages back and > forth > > (server and client #2). I'm not sure if hessian is the way to go. Maybe > a > > plain tcp socket would be better to push events from the sever to > desktop > > clients. > > I think you've go to back and be clear in your mind what Hessian > actually is, because it is not a network protocol. > > Hessian is a binary data binding protocol that defines a language > neutral wire format for transporting application level data > structures. > > The problem that Hessian solves is dealing with data marshalling and > unmarshalling over the wire in a compact and language fashion. Nothing > more, nothing less. > > Hessian assumes nothing about the underlying transport mechanism, so > how you do the IO is totally up to you. So Hessian can work with raw > TCP sockets, HTTP, Servlets (which is an API not a protocol), UDP (if > you deal with the framing), basically any transport that can > encapsulate opaque binary data. For example, you can encode > application layer data in messages using protocols such as AMQP (or > probably any other MOM API) or an API such as JMS. > > Given your problem, I would not be primarily worried about the data > binding layer first, I would sort out the data transport first. For > example, what physical transport are you going to use to have the > desktops subscribe to your server? TCP I think. Since clients must subscribe to events that the server is responsible for publishing. Are you going to poll the server in > a request/response fashion, open up a socket listener on each desktop > or are you going to use a messaging solution? Then if you can't > multicast, why are you using UDP in the first place? I'm using UDP becase thats what I have to talk to the network devices I have. If you are just > using it as a single unidirectional channel, you will still have to > deal with framing, acks, dropped datagrams and duplicate deliveries, > so add the overhead of TCP into the application layer and have > re-invented the wheel. I agree with you. I'd like to use TCP, but I can't :( So I would worry about the transport first, knowing that whatever I > choose, Hessian is simple and powerful enough to encode/decode data > onto/from the wire. Great. Thanks for the explanation. I'm considering the options I have, but thanks for your help. -- Leandro Rodrigo Saad Cruz software developer - certified scrum master :: scrum.com.br :: db.apache.org/ojb :: guara-framework.sf.net :: xingu.sf.net
_______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
