On Aug 1 2013 8:00 AM, Michael Haberler wrote:
> Am 01.08.2013 um 15:50 schrieb EBo :
>
>> On Aug 1 2013 7:45 AM, Dave wrote:
>>> On 8/1/2013 7:53 AM, Michael Haberler wrote:
I rule out an RPC server for retrieving a globally-unique serial,
this doesnt scale.
>>>
>>> Use a random 32
Am 01.08.2013 um 16:04 schrieb Ian McMahon :
> Perhaps a GUID mechanism that hashes machine info and system clock. If
> multiple systems are involved, the system clocks need to be synchronized for
> ordering.
The requirement IMO are: no acks may be lost; serials must be ordered until
proven
Perhaps a GUID mechanism that hashes machine info and system clock. If
multiple systems are involved, the system clocks need to be synchronized for
ordering.
On Aug 1, 2013, at 10:00 AM, Michael Haberler wrote:
>
> Am 01.08.2013 um 15:50 schrieb EBo :
>
>> On Aug 1 2013 7:45 AM, Dave wrote
Am 01.08.2013 um 15:50 schrieb EBo :
> On Aug 1 2013 7:45 AM, Dave wrote:
>> On 8/1/2013 7:53 AM, Michael Haberler wrote:
>>> I rule out an RPC server for retrieving a globally-unique serial,
>>> this doesnt scale.
>>>
>>
>> Use a random 32 bit number?
>
> I know that there are lots of system
On Aug 1 2013 7:45 AM, Dave wrote:
> On 8/1/2013 7:53 AM, Michael Haberler wrote:
>> I rule out an RPC server for retrieving a globally-unique serial,
>> this doesnt scale.
>>
>
> Use a random 32 bit number?
I know that there are lots of systems that have to deal with this kind
of thing. Does a
On 8/1/2013 7:53 AM, Michael Haberler wrote:
> I rule out an RPC server for retrieving a globally-unique serial, this doesnt
> scale.
>
Use a random 32 bit number?
Dave
--
Get your SQL database under version control
Am 01.08.2013 um 11:14 schrieb Frank Tkalcevic :
> Isn't this just the fact that the buffers can't be shared? If you want a
> command buffer don't you need to edit the linuxcnc.nml file and allocate a
> buffer for you process with a unique name?
I think there are in fact two separate issues at
