I had considered this approach but I wasn't quite sure where to start. If you have some links I could look through I'll weight it against my current solution.
Nathan On Thu, Jul 1, 2010 at 9:48 PM, jgilkey <[email protected]> wrote: > Jist my $0.02 but a WCF peer channel might work. > > On Jun 16, 8:17 pm, Nathan Palmer <[email protected]> wrote: >> Agreed. UDP would be fine in my scenario. In fact since I do not need >> durable storage some type of queue that was all in memory would work >> just fine too. That is why I had questioned whether or not I'm using >> the right technology. Since it was so easy to setup the queue and the >> communication with Rhino ESB I haven't looked for something else. >> >> Nathan >> >> >> >> On Wed, Jun 16, 2010 at 12:16 AM, Ayende Rahien <[email protected]> wrote: >> > Nathan, >> > If that is the case, you might want to consider using an unreliable >> > technology instead. >> > UDP, for example. >> >> > On Mon, Jun 14, 2010 at 8:43 PM, Nathan Palmer <[email protected]> >> > wrote: >> >> >> It's not important to receive prior notifications. In fact it would be >> >> confusing to the end user to receive those notifications. That is one >> >> reason why I had wondered if an ESB is the right technology here. >> >> >> I currently have it working using Rhino Queues with a random queue >> >> name and a randomly available port within a range. But with this i >> >> need to put in some code to cleanup the esent directories for the >> >> clients and manage the subscriptions. >> >> >> Nathan Palmer >> >> >> On Mon, Jun 14, 2010 at 7:29 AM, Corey Kaylor <[email protected]> wrote: >> >> > With multiple clients started at the same time under the same machine >> >> > when >> >> > using rhino queues you would need the ports to be a bit more dynamic >> >> > than >> >> > they are currently. Also, depending on the estimated number of clients >> >> > you >> >> > may want to manage your subscriptions carefully. In other words, if >> >> > there >> >> > are over 1000 and at any given time 500 are not running, this could >> >> > create a >> >> > bottleneck on the publishers sending queue. If a client goes offline, is >> >> > it >> >> > important to receive prior notifications? >> >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "Rhino Tools Dev" group. >> >> > To post to this group, send email to [email protected]. >> >> > To unsubscribe from this group, send email to >> >> > [email protected]. >> >> > For more options, visit this group at >> >> >http://groups.google.com/group/rhino-tools-dev?hl=en. >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> >> "Rhino Tools Dev" group. >> >> To post to this group, send email to [email protected]. >> >> To unsubscribe from this group, send email to >> >> [email protected]. >> >> For more options, visit this group at >> >>http://groups.google.com/group/rhino-tools-dev?hl=en. >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Rhino Tools Dev" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> >http://groups.google.com/group/rhino-tools-dev?hl=en.- Hide quoted text - >> >> - Show quoted text - > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
