The biggest problem with 280, mostly idle, threads would be the amount of
stack space the OS is required to reserve (1MB for Windows/2MB for Linux).
On a 64bit host this is unlikely to be much of an issue.
On Mon, Dec 15, 2014 at 6:11 AM, Pieter Hintjens p...@imatix.com wrote:
280 threads
Modern Linux doesn't actually map stack space into real memory unless the
thread accesses the virtual memory addresses on demand. I presume it's the
same for Windows. Garrett Smith pointed this out to me when I made the
same claim at the Chicago meetup a couple years ago.
-Michel
On Thu, Dec
280 threads sounds fine unless you have data showing that it's a
problem. That's easy to test on your target platform.
On Sun, Dec 14, 2014 at 7:54 AM, Bob Clarke optiongu...@gmail.com wrote:
Platform: 0MQ 4.0.4 on Windows 7/Windows Server 2008
I am writing a server monitoring program to
Platform: 0MQ 4.0.4 on Windows 7/Windows Server 2008
I am writing a server monitoring program to replace an ancient (1999)
program that is almost impossible to maintain.
All of our application servers host proprietary Windows services written in
C++ (except for a couple .Net apps) that use a
On Nov 16, 2011, at 1:19 AM, Martin Sustrik wrote:
Hi Chuck,
The UUID would uniquely identify each client.
Give some thought to what do you want to uniquely identify. Is it any client
ever? If so, UUID is probably the right way to go. However, if all you need
is to uniquely identify a
On Wed, Nov 16, 2011 at 9:11 AM, Chuck Remes cremes.devl...@mac.com wrote:
I need to uniquely identify the client for the life of the service. I assume
the service could live for days, weeks or months (years seems a stretch). How
would I choose a 32-bit integer independently from many hosts
On Nov 16, 2011, at 10:22 AM, Pieter Hintjens wrote:
On Wed, Nov 16, 2011 at 9:11 AM, Chuck Remes cremes.devl...@mac.com wrote:
I need to uniquely identify the client for the life of the service. I assume
the service could live for days, weeks or months (years seems a stretch).
How would
On Wed, Nov 16, 2011 at 10:34 AM, Chuck Remes cremes.devl...@mac.com wrote:
This would require the Client portion of the protocol to include a READY-type
message so it could be assigned an ID by the Broker. I'll look at this.
Something like that. There are also arguments against
On 11/16/2011 06:46 PM, Pieter Hintjens wrote:
There are also arguments against broker-assigned
identifiers, mainly if brokers restart and thousands of clients all
demand new identities at the same time, it can be painful.
One little known feature of 0MQ is that reconnection times are
Another way of identifying a client is a certificate. How will you support
that?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
On Nov 16, 2011, at 4:21 PM, Ernest Lee wrote:
Another way of identifying a client is a certificate. How will you support
that? ___
I have no idea. It's not even a consideration. Is there something you would
recommend I read (that is not
On Wed, Nov 16, 2011 at 4:49 PM, Chuck Remes cremes.devl...@mac.com wrote:
Another way of identifying a client is a certificate. How will you support
that? ___
I have no idea. It's not even a consideration. Is there something you would
recommend
Hi Chuck,
On Wed, Nov 16, 2011 at 7:11 AM, Chuck Remes cremes.devl...@mac.com wrote:
On Nov 16, 2011, at 1:19 AM, Martin Sustrik wrote:
Hi Chuck,
The UUID would uniquely identify each client.
Give some thought to what do you want to uniquely identify. Is it any client
ever? If so, UUID
I am working on a protocol for submission to the rfc.zeromq.com site. For one
of the fields (message frames) I need to define a unique sequence number. I
decided upon a combination of a 64-bit integer and a 16-byte UUID.
The UUID would uniquely identify each client. The sequence number would
Why not if you proper handle endianness?
Alexander
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Chuck Remes
Sent: Tuesday, November 15, 2011 10:59 PM
To: ZeroMQ development list
Subject: [zeromq-dev] protocol
, 2011 10:59 PM
To: ZeroMQ development list
Subject: [zeromq-dev] protocol design question
I am working on a protocol for submission to the rfc.zeromq.com site.
For one of the fields (message frames) I need to define a unique
sequence number. I decided upon a combination of a 64-bit integer
On Tue, Nov 15, 2011 at 1:59 PM, Chuck Remes cremes.devl...@mac.com wrote:
For one of the fields (message frames) I need to define a unique sequence
number. I decided upon a combination of a 64-bit integer and a 16-byte UUID.
The UUID would uniquely identify each client. The sequence number
On Nov 15, 2011, at 2:36 PM, MinRK wrote:
e.g.
struct sequence_id {
uint64 number;
uchar uuid[16];
};
Is this all right? Or is there a better way to accomplish this framing?
cr
I have a general question related to this - what is the relative cost in
zeromq of these being
On Nov 15, 2011, at 2:37 PM, Pieter Hintjens wrote:
On Tue, Nov 15, 2011 at 1:59 PM, Chuck Remes cremes.devl...@mac.com wrote:
Is it portable to pack them both into the same frame like this? I assume a C
user could define a struct to map that frame directly.
Sure, this is a good
On Nov 15, 2011, at 12:45, Chuck Remes cremes.devl...@mac.com wrote:
On Nov 15, 2011, at 2:36 PM, MinRK wrote:
e.g.
struct sequence_id {
uint64 number;
uchar uuid[16];
};
Is this all right? Or is there a better way to accomplish this framing?
cr
I have a general question
Hi Chuck,
The UUID would uniquely identify each client.
Give some thought to what do you want to uniquely identify. Is it any
client ever? If so, UUID is probably the right way to go. However, if
all you need is to uniquely identify a client of a particular server
instance, 32-bit integer
21 matches
Mail list logo
