From: White, G. <gr...@sl...> - 2012-02-24 16:56:08
|
Colleagues, please find Philip's invited review below. Let me not comment in depth, but Philip's comment on how to determine endianess looks like we've come full circle. Made me smile. Thanks very much again Philip. Would you mind if we add your name as an invited reviewer? Also philip, can I add you to the mailing list, for now, so you can see protocol comments? Cheers Greg Begin forwarded message: From: "Duval, Philip" <phi...@de...> Subject: RE: Invited Expert Review Date: 24 February 2012 16:50:25 CET To: "Greg White" <Gre...@ps...> Hello Greg, Well, we're still not officially at the 'end of the week', so here are my promised thoughts (maybe not quite in the nick of time). I've just dumped them into the email, but I've got a Word .doc if you need it. Cheers, Phil General Comments to the PvAccess Protocol Specification Document (Working Draft 20-Feb-2012) The draft seems basically sound. At some stage this should be proof read by a native English-speaker. I will otherwise try to comment on the contents as I interpret them. As an outsider (familiar with all details of the TINE protocol) I naturally tend to try put things into contexts and terminology that I understand and this might miss the mark occasionally. Although some aspects and strategies I would either do differently or leave behind, I don't find see anything objectionable or which cannot be made to work as described. Nonetheless I will share some questions and comments below. Overview: "all addresses are IPv6 encoded". Most institutes will continue to use IPv4 for some time to come (IPv6 still only accounts for about 10% of the networks on the internet, worldwide). Will IPv4 addresses be encoded following some dual/stack encoding standard (e.g. first 80 bits set to 0, next 16 = 1, last 32 = the IPv4 address) or is something else envisioned? Last time I looked, there was no de-facto mapping, but a couple of emerging standards. Data Encoding: I'm assuming the alignment requirements for arrays are due to the 'leading' length parameter? If the length were a set 32 bit integer for example, then the position of each element in a number array is known, if not already aligned. An array of 'free' strings is another matter (but here alignment is not an issue). Having a leading 'size' that is mostly a byte, but sometimes a short or an int looks like a complicating factor to me. Here I would debate whether it is 'significantly cheaper' to do this than always sending a 32-bit integer. It might indeed be so, if one prefixes arrays, i.e. arrays of characters that make strings which might make up a sequence of strings, with their sizes. I can only contrast to what TINE does. Namely an array of free strings (or anything else, for that matter) presents a 'size' as has how many of the canonical type size follows in the payload. So you'd have the number of chars (bytes) in the entire string space coming, followed by the string space. The string elements are NOT prefixed with a size, but are null-terminated. And in either case, you have to scan through the payload to, for instance, find string number '5'. If the accompanying header is modulo 8 bytes, then the data payload is aligned. Is the concern about 'packing'? That is, collecting a number of responses N that are scheduled to be delivered to a client? Here it's true: you might want to try to in some way reduce duplicate information in N headers. Including the endian-ness in the message headers may or may not be a complication. As long as the server decides what endian-ness it is using, this could save unnecessary byte swapping when a java server sends to a java client (even though both are running on Intel hosts). Here I don't get the distinction being made between endian-ness and connection-oriented communication versus connectionless. A payload is a payload (whether delivered via datagram or stream). Is my confusion once again related to my trying to interpret 'PvData' as 'Contracts with Properties'? Structures: The 'ID' most definitely needs to be associated with the sender to uniquely identify it, as long as different user-types with same ID can come from different servers. But different server can (and will) sometimes WANT to use the same ID. Flow Control: Here I would not bother with this. This is probably because I'm lazy, but I admit it would be fun to try. TCP basically does this okay, and 'buffer bloat' can also occur in the routers and switches between peers. But I'm not sure what you do with a failed 'send'. A failed 'send' (end point can't buffer and doesn't ACK) will force a decision at the sender (try again or drop) (TINE will try again once). So when things 'go bad', either a client misses updates (even though it's a stream) or the client updates are jittery or 'late', because payloads have been lying around in RCV buffers for a while. Presumably, you're attempting to keep the RCV Buffers large but also be able to throw away stuff earlier at the sender to try to get back to the 'most recent' updates as fast as possible? Certainly, as you allude, you'll want to be able to set this. Display updates only want the most recent data. Automation middle layers will need to take whatever steps necessary to avoid buffering problems and 'get it all'. Message header: The 'flags' parameter gives the endian-ness. I'm assuming this is used immediately to see what to do with the 'payloadSize' parameter, as this is an 'int'? Beacons: Your beacons are broadcasting/multicasting with IPv4 and/or IPv6? Is that configurable? The beacon header contains an IPv6 address. Theoretically you can get the IP address of the incoming datagram out of the Network stack (either v6 or v4). Or is this giving me another address? Connection Validation I admit that it might be nice to have a connection validation message, but I don't follow the race condition argument. In TINE a client will get a timeout one way or the other and can 'safely reissue any request'. The request, if there's running server, will only exist 'once' in a table at the server and only ever exist 'once' in a table in the client. But I'm once again probably missing the finer details. On the other hand, sending buffer size information, etc. with this message is useful information. QoS: "Each QoS parameter value REQUIRES a separate TCP/IP connection." And a separate thread? TINE typically uses a single TCP/IP connection and thread per connected client (although there are 2 different kinds of TCP connections to choose from). My usual concerns here would be about 'causality': Minimum latency command sets value to '5'; not so minimum latency monitor still receives value '10' for a cycle or two; operator at the other end of the panel is confused. I notice you still have a bit of a 'TODO' list. But a question about 'put-get': is this 'atomic'? Thinking 'like a database', is the record locked between the 'put' and the 'get'? > -----Original Message----- > From: Greg White [mailto:Gre...@ps...] > Sent: Monday, 20 February, 2012 16:30 > To: Duval, Philip > Cc: epi...@li... Developers > Subject: Invited Expert Review > > Philip, > > We have a candidate draft of the EPICS V4 pvAccess protocol [1] as presented > by Matej > at the BNL meeting in January. > > Could we ask you to be an invited expert reviewer? > > We would like to publish a 2nd Public Working Draft based on this file late this > week, > so if your review is extensive your comment material would go into a > subsequent draft. > > Thanks very much in advance, > Greg > > > [1] http://epics-pvdata.hg.sourceforge.net/hgweb/epics- > pvdata/pvDataWWW/raw- > file/tip/mainPage/pvAccess_Protocol_Specification.html > > |
From: Duval, P. <phi...@de...> - 2012-02-27 17:29:37
|
Hello Matej, Thanks for the info! One or two comments to your comments below ... >Hi, > >find my answers inline: > >> Overview: >> "all addresses are IPv6 encoded". Most institutes will continue to use >> IPv4 for some time to come (IPv6 still only accounts for about 10% of >> the networks on the internet, worldwide). Will IPv4 addresses be >> encoded following some dual/stack encoding standard (e.g. first 80 bits >> set to 0, next 16 = 1, last 32 = the IPv4 address) or is something else >> envisioned? Last time I looked, there was no de-facto mapping, but a >> couple of emerging standards. > >Here is the description how IPv4 address is encoded in IPv6. > >http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses > So, indeed, the "hybrid dual-stack" variant! >> Data Encoding: >> I'm assuming the alignment requirements for arrays are due to the >> 'leading' length parameter? >> If the length were a set 32 bit integer for >> example, then the position of each element in a number array is known, >> if not already aligned. An array of 'free' strings is another matter >> (but here alignment is not an issue). > >Not really. To speed-up byte-swapping of really large arrays. >Alignment requirement is only for number arrays. > I would have thought that with modulo 8 headers, number-array payloads would be aligned right off the bat, but I'll take your word for it. (And you don't need things to be aligned to do byte swapping, e.g. a 'mem-reverse' technique with a couple of XORs doesn't care where the beginning address is - but maybe you've got something more optimized). >> Having a leading 'size' that is mostly a byte, but sometimes a short or >> an int looks like a complicating factor to me. Here I would debate >> whether it is 'significantly cheaper' to do this than always sending a >> 32-bit integer. It might indeed be so, if one prefixes arrays, i.e. >> arrays of characters that make strings which might make up a sequence of >> strings, with their sizes. > >Currently we have: byte, 32-integer, 64-integer; some use 16-integer >but I do not find it useful. >64-integer was added to the future. > >> I can only contrast to what TINE does. >> Namely an array of free strings (or anything else, for that matter) >> presents a 'size' as has how many of the canonical type size follows in >> the payload. So you'd have the number of chars (bytes) in the entire >> string space coming, followed by the string space. The string elements >> are NOT prefixed with a size, but are null-terminated. And in either >> case, you have to scan through the payload to, for instance, find string >> number '5'. If the accompanying header is modulo 8 bytes, then the data >> payload is aligned. Is the concern about 'packing'? That is, >> collecting a number of responses N that are scheduled to be delivered to >> a client? Here it's true: you might want to try to in some way reduce >> duplicate information in N headers. > >Regarding string (array) serialization: I really do not like to scan >strings for null characters (especially if they are UTF-8). Using >leading string size and do a 'memcpy' does it. > Correct! De-serializing the string payload into something the caller wants will be a tad faster if you don't have to scan for the terminating '0'. On the other hand, I've never seen a client application that has needed to be ultra-efficient with string arrays. These are usually quasi-static lists, queried once. Without knowing any other details, I was just pondering whether these concerns for strings were the driving force behind the 'don't-use-a-32-bit-integer-all-the-time' decision for your size. In any event, if you've got something that works the way you want it, for heaven's sake, keep it! >> Including the endian-ness in the message headers may or may not be a >> complication. As long as the server decides what endian-ness it is >> using, this could save unnecessary byte swapping when a java server >> sends to a java client (even though both are running on Intel hosts). >> Here I don't get the distinction being made between endian-ness and >> connection-oriented communication versus connectionless. A payload is a >> payload (whether delivered via datagram or stream). > >Why we need that flag: >1) Think of UDP search messages. >2) Gateway only forwards servers' messages (servers may use different >byte order). > What's a "UDP search message"? I've got you covered on the benefits of passing the endian flag along (and byte swapping or not according to need). But if you're sending the same payload via UDP or via TCP depending on how the client has asked for it (or is this not an option?), then I'm still going to have to know whether to swap or not (or is UDP big-endian only or something)? When your document suddenly brings up "For connection-oriented communication ..." and later "... connection-less protocols", when discussing the endian-ness, it got me confused. So are you saying that you never use UDP to send pvData around, but only use UDP for some sort of search messages? >> Is my confusion once again related to my trying to interpret 'PvData' as >> 'Contracts with Properties'? >> >> Structures: >> The 'ID' most definitely needs to be associated with the sender to >> uniquely identify it, as long as different user-types with same ID can >> come from different servers. But different server can (and will) >> sometimes WANT to use the same ID. > >Introspection data cache (introspection registry) IDs are valid only >within one connection; no sharing between 2 connections, between >servers, etc. > Okay. > >> Flow Control: >> Here I would not bother with this. This is probably because I'm lazy, >> but I admit it would be fun to try. TCP basically does this okay, and >> 'buffer bloat' can also occur in the routers and switches between peers. >> But I'm not sure what you do with a failed 'send'. A failed 'send' (end >> point can't buffer and doesn't ACK) will force a decision at the sender >> (try again or drop) (TINE will try again once). > >Here you are talking UDP. No, I'm not. >If you miss a byte in TCP you are lost (I do not believe in recovery >here...), however you cannot miss a byte using TCP. Non-blocking TCP >socket will simply return 0 bytes where sent (meaning send buffer is >full, most likely caused by full receive buffer of a receiver). > If you select() on send buffers first (before you try to send() - via TCP), you won't see any ready if there aren't any. Here, you could try again in a clock tick or something. >> So when things 'go >> bad', either a client misses updates (even though it's a stream) or the >> client updates are jittery or 'late', because payloads have been lying >> around in RCV buffers for a while. Presumably, you're attempting to >> keep the RCV Buffers large but also be able to throw away stuff earlier >> at the sender to try to get back to the 'most recent' updates as fast as >> possible? Certainly, as you allude, you'll want to be able to set this. >> Display updates only want the most recent data. Automation middle >> layers will need to take whatever steps necessary to avoid buffering >> problems and 'get it all'. > >Sure, but the idea is to get less jittery monitors, to minimize 'buffer bloat'. >It's a finesse I would say. > I would also say it's a finesse. I was just wondering if it were worth the trouble. For example, the last time we noticed any sort of jitter here (with video frames coming in at a rather high rate) it turned out to be due to improper flow-control settings on the ethernet card the Win7 client. >> Message header: >> The 'flags' parameter gives the endian-ness. I'm assuming this is used >> immediately to see what to do with the 'payloadSize' parameter, as this >> is an 'int'? > >Right (not needed to check if every time if endian-ness is already negotiated). > >> Beacons: >> Your beacons are broadcasting/multicasting with IPv4 and/or IPv6? Is >> that configurable? The beacon header contains an IPv6 address. > >Can be both. Yes, you can provide address where to send beacons. > >> Theoretically you can get the IP address of the incoming datagram out of >> the Network stack (either v6 or v4). Or is this giving me another >> address? > >For sure you need port since there might be different pvAccess server >running on the same machine. > You can get the port out of the incoming network address as well. Or is there one 'beacon' per host? Sorry, my epics ignorance is showing. Oops: just had a look at your email part II. So, I might get a beacon message via some other protocol? The rest, you answered to my satisfaction. Thanks again, Phil >> Connection Validation >> I admit that it might be nice to have a connection validation message, >> but I don't follow the race condition argument. In TINE a client will >> get a timeout one way or the other and can 'safely reissue any request'. >> The request, if there's running server, will only exist 'once' in a >> table at the server and only ever exist 'once' in a table in the client. >> But I'm once again probably missing the finer details. On the other >> hand, sending buffer size information, etc. with this message is useful >> information. >> >> QoS: >> "Each QoS parameter value REQUIRES a separate TCP/IP connection." And a >> separate thread? TINE typically uses a single TCP/IP connection and >> thread per connected client (although there are 2 different kinds of TCP >> connections to choose from). My usual concerns here would be about >> 'causality': Minimum latency command sets value to '5'; not so minimum >> latency monitor still receives value '10' for a cycle or two; operator >> at the other end of the panel is confused. >> >> I notice you still have a bit of a 'TODO' list. But a question about >> 'put-get': is this 'atomic'? Thinking 'like a database', is the record >> locked between the 'put' and the 'get'? >> >>> -----Original Message----- >>> From: Greg White [mailto:Gre...@ps...] >>> Sent: Monday, 20 February, 2012 16:30 >>> To: Duval, Philip >>> Cc: epi...@li... Developers >>> Subject: Invited Expert Review >>> >>> Philip, >>> >>> We have a candidate draft of the EPICS V4 pvAccess protocol [1] as >> presented >>> by Matej >>> at the BNL meeting in January. >>> >>> Could we ask you to be an invited expert reviewer? >>> >>> We would like to publish a 2nd Public Working Draft based on this file >> late this >>> week, >>> so if your review is extensive your comment material would go into a >>> subsequent draft. >>> >>> Thanks very much in advance, >>> Greg >>> >>> >>> [1] http://epics-pvdata.hg.sourceforge.net/hgweb/epics- >>> pvdata/pvDataWWW/raw- >>> file/tip/mainPage/pvAccess_Protocol_Specification.html >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ |
From: Matej S. <mat...@co...> - 2012-02-27 18:13:39
|
>>Not really. To speed-up byte-swapping of really large arrays. >>Alignment requirement is only for number arrays. >> > > I would have thought that with modulo 8 headers, number-array payloads would be aligned right off the bat, but I'll take your word for it. Before the array there may be arbitrary fields... > (And you don't need things to be aligned to do byte swapping, e.g. a 'mem-reverse' technique with a couple of XORs doesn't care where the beginning address is - but maybe you've got something more optimized). It's not required, but it's slower. Intel (x86) and successors are very good at handling unaligned access. However some CPUs trap unaligned accesses to the operating system where they can either be ignored (very bad), simulated (much slower) or reported as errors (bad). >>> Including the endian-ness in the message headers may or may not be a >>> complication. As long as the server decides what endian-ness it is >>> using, this could save unnecessary byte swapping when a java server >>> sends to a java client (even though both are running on Intel hosts). >>> Here I don't get the distinction being made between endian-ness and >>> connection-oriented communication versus connectionless. A payload is a >>> payload (whether delivered via datagram or stream). >> >>Why we need that flag: >>1) Think of UDP search messages. >>2) Gateway only forwards servers' messages (servers may use different >>byte order). >> > > What's a "UDP search message"? CA (and pvAccess) uses broadcast/multicast to find server hosting requested channel(s) - no need for centralized naming server. > I've got you covered on the benefits of passing the endian flag along (and byte swapping or not according to need). But if you're sending the same payload via UDP or via TCP depending on how the client has asked for it (or is this not an option?), then I'm still going to have to know whether to swap or not (or is UDP big-endian only or something)? When your document suddenly brings up "For connection-oriented communication ..." and later "... connection-less protocols", when discussing the endian-ness, it got me confused. So are you saying that you never use UDP to send pvData around, but only use UDP for some sort of search messages? Correct. In the future there might be an UDP implementation. The same is with currently used CA. > I would also say it's a finesse. I was just wondering if it were worth the trouble. For example, the last time we noticed any sort of jitter here (with video frames coming in at a rather high rate) it turned out to be due to improper flow-control settings on the ethernet card the Win7 client. That's why I have Flow control section in italic (I am not convinced it's worth the trouble). I like things simple as possible. > You can get the port out of the incoming network address as well. Or is there one 'beacon' per host? Sorry, my epics ignorance is showing. You may have several servers on the same host. So, you need at least port to know whose beacon have you received. There should be a beacon sender per server instance. > Oops: just had a look at your email part II. So, I might get a beacon message via some other protocol? Beacons contain address of a server listening port (not where it come from - that info is given from the recvfrom). Spec. is open to all other protocols that may be implemented in the future. Cheers, Matej |
From: Dalesio, L. <da...@bn...> - 2012-02-27 18:44:07
|
>CA (and pvAccess) uses broadcast/multicast to find server hosting >requested channel(s) - no need for centralized naming server. I think Phil is asking if we use UDP for sending out data - as in multicast for large arrays. As we move into more data acquisition type applications it will be important to consider data acquisition. |
From: Matej S. <mat...@co...> - 2012-02-27 13:32:04
|
Hi, find my answers inline: > Overview: > "all addresses are IPv6 encoded". Most institutes will continue to use > IPv4 for some time to come (IPv6 still only accounts for about 10% of > the networks on the internet, worldwide). Will IPv4 addresses be > encoded following some dual/stack encoding standard (e.g. first 80 bits > set to 0, next 16 = 1, last 32 = the IPv4 address) or is something else > envisioned? Last time I looked, there was no de-facto mapping, but a > couple of emerging standards. Here is the description how IPv4 address is encoded in IPv6. http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses > Data Encoding: > I'm assuming the alignment requirements for arrays are due to the > 'leading' length parameter? > If the length were a set 32 bit integer for > example, then the position of each element in a number array is known, > if not already aligned. An array of 'free' strings is another matter > (but here alignment is not an issue). Not really. To speed-up byte-swapping of really large arrays. Alignment requirement is only for number arrays. > Having a leading 'size' that is mostly a byte, but sometimes a short or > an int looks like a complicating factor to me. Here I would debate > whether it is 'significantly cheaper' to do this than always sending a > 32-bit integer. It might indeed be so, if one prefixes arrays, i.e. > arrays of characters that make strings which might make up a sequence of > strings, with their sizes. Currently we have: byte, 32-integer, 64-integer; some use 16-integer but I do not find it useful. 64-integer was added to the future. > I can only contrast to what TINE does. > Namely an array of free strings (or anything else, for that matter) > presents a 'size' as has how many of the canonical type size follows in > the payload. So you'd have the number of chars (bytes) in the entire > string space coming, followed by the string space. The string elements > are NOT prefixed with a size, but are null-terminated. And in either > case, you have to scan through the payload to, for instance, find string > number '5'. If the accompanying header is modulo 8 bytes, then the data > payload is aligned. Is the concern about 'packing'? That is, > collecting a number of responses N that are scheduled to be delivered to > a client? Here it's true: you might want to try to in some way reduce > duplicate information in N headers. Regarding string (array) serialization: I really do not like to scan strings for null characters (especially if they are UTF-8). Using leading string size and do a 'memcpy' does it. > Including the endian-ness in the message headers may or may not be a > complication. As long as the server decides what endian-ness it is > using, this could save unnecessary byte swapping when a java server > sends to a java client (even though both are running on Intel hosts). > Here I don't get the distinction being made between endian-ness and > connection-oriented communication versus connectionless. A payload is a > payload (whether delivered via datagram or stream). Why we need that flag: 1) Think of UDP search messages. 2) Gateway only forwards servers' messages (servers may use different byte order). > Is my confusion once again related to my trying to interpret 'PvData' as > 'Contracts with Properties'? > > Structures: > The 'ID' most definitely needs to be associated with the sender to > uniquely identify it, as long as different user-types with same ID can > come from different servers. But different server can (and will) > sometimes WANT to use the same ID. Introspection data cache (introspection registry) IDs are valid only within one connection; no sharing between 2 connections, between servers, etc. > Flow Control: > Here I would not bother with this. This is probably because I'm lazy, > but I admit it would be fun to try. TCP basically does this okay, and > 'buffer bloat' can also occur in the routers and switches between peers. > But I'm not sure what you do with a failed 'send'. A failed 'send' (end > point can't buffer and doesn't ACK) will force a decision at the sender > (try again or drop) (TINE will try again once). Here you are talking UDP. If you miss a byte in TCP you are lost (I do not believe in recovery here...), however you cannot miss a byte using TCP. Non-blocking TCP socket will simply return 0 bytes where sent (meaning send buffer is full, most likely caused by full receive buffer of a receiver). > So when things 'go > bad', either a client misses updates (even though it's a stream) or the > client updates are jittery or 'late', because payloads have been lying > around in RCV buffers for a while. Presumably, you're attempting to > keep the RCV Buffers large but also be able to throw away stuff earlier > at the sender to try to get back to the 'most recent' updates as fast as > possible? Certainly, as you allude, you'll want to be able to set this. > Display updates only want the most recent data. Automation middle > layers will need to take whatever steps necessary to avoid buffering > problems and 'get it all'. Sure, but the idea is to get less jittery monitors, to minimize 'buffer bloat'. It's a finesse I would say. > Message header: > The 'flags' parameter gives the endian-ness. I'm assuming this is used > immediately to see what to do with the 'payloadSize' parameter, as this > is an 'int'? Right (not needed to check if every time if endian-ness is already negotiated). > Beacons: > Your beacons are broadcasting/multicasting with IPv4 and/or IPv6? Is > that configurable? The beacon header contains an IPv6 address. Can be both. Yes, you can provide address where to send beacons. > Theoretically you can get the IP address of the incoming datagram out of > the Network stack (either v6 or v4). Or is this giving me another > address? For sure you need port since there might be different pvAccess server running on the same machine. > Connection Validation > I admit that it might be nice to have a connection validation message, > but I don't follow the race condition argument. In TINE a client will > get a timeout one way or the other and can 'safely reissue any request'. > The request, if there's running server, will only exist 'once' in a > table at the server and only ever exist 'once' in a table in the client. > But I'm once again probably missing the finer details. On the other > hand, sending buffer size information, etc. with this message is useful > information. > > QoS: > "Each QoS parameter value REQUIRES a separate TCP/IP connection." And a > separate thread? TINE typically uses a single TCP/IP connection and > thread per connected client (although there are 2 different kinds of TCP > connections to choose from). My usual concerns here would be about > 'causality': Minimum latency command sets value to '5'; not so minimum > latency monitor still receives value '10' for a cycle or two; operator > at the other end of the panel is confused. > > I notice you still have a bit of a 'TODO' list. But a question about > 'put-get': is this 'atomic'? Thinking 'like a database', is the record > locked between the 'put' and the 'get'? > >> -----Original Message----- >> From: Greg White [mailto:Gre...@ps...] >> Sent: Monday, 20 February, 2012 16:30 >> To: Duval, Philip >> Cc: epi...@li... Developers >> Subject: Invited Expert Review >> >> Philip, >> >> We have a candidate draft of the EPICS V4 pvAccess protocol [1] as > presented >> by Matej >> at the BNL meeting in January. >> >> Could we ask you to be an invited expert reviewer? >> >> We would like to publish a 2nd Public Working Draft based on this file > late this >> week, >> so if your review is extensive your comment material would go into a >> subsequent draft. >> >> Thanks very much in advance, >> Greg >> >> >> [1] http://epics-pvdata.hg.sourceforge.net/hgweb/epics- >> pvdata/pvDataWWW/raw- >> file/tip/mainPage/pvAccess_Protocol_Specification.html >> >> > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ |
From: Matej S. <mat...@co...> - 2012-02-27 13:45:32
|
I apologize. I've clicked sent to soon. > Theoretically you can get the IP address of the incoming datagram out of > the Network stack (either v6 or v4). Or is this giving me another > address? For sure you need port since there might be different pvAccess server running on the same machine. Usually it is the same, but might be different (e.g. if non-IP protocol is used). > QoS: > "Each QoS parameter value REQUIRES a separate TCP/IP connection." And a > separate thread? No need with asynchronous IO (ASIO). In Java I have both implemented: blocking socket and ASIO. Each has its own advantages. > TINE typically uses a single TCP/IP connection and > thread per connected client (although there are 2 different kinds of TCP > connections to choose from). My usual concerns here would be about > 'causality': Minimum latency command sets value to '5'; not so minimum > latency monitor still receives value '10' for a cycle or two; operator > at the other end of the panel is confused. Since Rx and Tx are decoupled and there are buffers in between (and messages need some finite time to get over the network) you cannot avoid this. The above example "set" and "monitor" actions that are decoupled. You need to sync it: do a put and get. Or put-get. > I notice you still have a bit of a 'TODO' list. But a question about > 'put-get': is this 'atomic'? Thinking 'like a database', is the record > locked between the 'put' and the 'get'? Yes. Matej |