Re: Re: [PATCH V4 1/5] trace-cmd/listen: Apply the trace-msg protocol for communication between a server and clients
Hi Steven, Thank you for your review. (2014/07/23 0:04), Steven Rostedt wrote: Sorry for taking so long to reply, I've been hacking on the kernel a bit and that takes precedence over user tools :-/ On Fri, 11 Jul 2014 00:58:26 + Yoshihiro YUNOMAE wrote: Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: listen to socket fd connect to socket fd accept the client send "tracecmd" +> receive "tracecmd" check "tracecmd" send cpus receive cpus <+ print "cpus=XXX" send pagesize | receive pagesize <+ print "pagesize=XXX" send option | receive option <--+ understand option send port_array +> receive port_array understand port_array send meta data receive meta data <---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) All messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: listen to socket fd connect to socket fd accept the client send "tracecmd" +> receive "tracecmd" check "tracecmd" send "V2\0\00" as the v2 protocol Lets change this to "-1V2\0\00" The -1 will cause an old server to exit as it will not accept a -1 for CPU count. Then you can check if the return of the next read is -1, as the client would have disconnected. Sure. The reason I ask this, is because once you send a valid CPU count (and unfortunately, 0 happens to be valid :-p, the server side creates a file. When you close it, that file stays around as zero length. By sending -1, the old server will error out and never create a file. Yes, I also thought this should be fixed. I'll submit fixed patch. Thank you, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH V4 1/5] trace-cmd/listen: Apply the trace-msg protocol for communication between a server and clients
Hi Steven, Thank you for your review. (2014/07/23 0:04), Steven Rostedt wrote: Sorry for taking so long to reply, I've been hacking on the kernel a bit and that takes precedence over user tools :-/ On Fri, 11 Jul 2014 00:58:26 + Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: server client listen to socket fd connect to socket fd accept the client send tracecmd + receive tracecmd check tracecmd send cpus receive cpus + print cpus=XXX send pagesize | receive pagesize + print pagesize=XXX send option | receive option --+ understand option send port_array + receive port_array understand port_array send meta data receive meta data ---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) All messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: server client listen to socket fd connect to socket fd accept the client send tracecmd + receive tracecmd check tracecmd send V2\0MAGIC_NUMBER\00 as the v2 protocol Lets change this to -1V2\0MAGIC_NUMBER\00 The -1 will cause an old server to exit as it will not accept a -1 for CPU count. Then you can check if the return of the next read is -1, as the client would have disconnected. Sure. The reason I ask this, is because once you send a valid CPU count (and unfortunately, 0 happens to be valid :-p, the server side creates a file. When you close it, that file stays around as zero length. By sending -1, the old server will error out and never create a file. Yes, I also thought this should be fixed. I'll submit fixed patch. Thank you, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/5] trace-cmd/listen: Apply the trace-msg protocol for communication between a server and clients
Sorry for taking so long to reply, I've been hacking on the kernel a bit and that takes precedence over user tools :-/ On Fri, 11 Jul 2014 00:58:26 + Yoshihiro YUNOMAE wrote: > Apply trace-msg protocol for communication between a server and clients. > > Currently, trace-listen(server) and trace-record -N(client) operate as > follows: > > > listen to socket fd > connect to socket fd > accept the client > send "tracecmd" >+> receive "tracecmd" > check "tracecmd" > send cpus > receive cpus <+ > print "cpus=XXX" > send pagesize > | > receive pagesize <+ > print "pagesize=XXX" > send option > | > receive option <--+ > understand option > send port_array >+> receive port_array > understand port_array > send meta data > receive meta data <---+ > record meta data > (snip) > read block > --- start sending trace data on child processes --- > > --- When client finishes sending trace data --- > close(socket fd) > read size = 0 > close(socket fd) > > All messages are unstructured character strings, so server(client) using the > protocol must parse the unstructured messages. Since it is hard to > add complex contents in the protocol, structured binary message trace-msg > is introduced as the communication protocol. > > By applying this patch, server and client operate as follows: > > > listen to socket fd > connect to socket fd > accept the client > send "tracecmd" >+> receive "tracecmd" > check "tracecmd" > send "V2\0\00" as the v2 protocol Lets change this to "-1V2\0\00" The -1 will cause an old server to exit as it will not accept a -1 for CPU count. Then you can check if the return of the next read is -1, as the client would have disconnected. The reason I ask this, is because once you send a valid CPU count (and unfortunately, 0 happens to be valid :-p, the server side creates a file. When you close it, that file stays around as zero length. By sending -1, the old server will error out and never create a file. -- Steve > receive "V2" <+ > check "V2" > read "\00" > send "V2" > +---> receive "V2" > check "V2" > send cpus,pagesize,option(MSG_TINIT) > receive MSG_TINIT <---+ > print "cpus=XXX" > print "pagesize=XXX" > understand option > send port_array >+--MSG_RINIT-> receive MSG_RINIT > understand port_array > send meta data(MSG_SENDMETA) > receive MSG_SENDMETA <+ > record meta data > (snip) > send a message to finish sending meta data > | (MSG_FINMETA) > receive MSG_FINMETA <-+ > read block > --- start sending trace data on child processes --- > > --- When client finishes sending trace data --- > send MSG_CLOSE > receive MSG_CLOSE <---+ > close(socket fd)close(socket fd) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4 1/5] trace-cmd/listen: Apply the trace-msg protocol for communication between a server and clients
Sorry for taking so long to reply, I've been hacking on the kernel a bit and that takes precedence over user tools :-/ On Fri, 11 Jul 2014 00:58:26 + Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: server client listen to socket fd connect to socket fd accept the client send tracecmd + receive tracecmd check tracecmd send cpus receive cpus + print cpus=XXX send pagesize | receive pagesize + print pagesize=XXX send option | receive option --+ understand option send port_array + receive port_array understand port_array send meta data receive meta data ---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) All messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: server client listen to socket fd connect to socket fd accept the client send tracecmd + receive tracecmd check tracecmd send V2\0MAGIC_NUMBER\00 as the v2 protocol Lets change this to -1V2\0MAGIC_NUMBER\00 The -1 will cause an old server to exit as it will not accept a -1 for CPU count. Then you can check if the return of the next read is -1, as the client would have disconnected. The reason I ask this, is because once you send a valid CPU count (and unfortunately, 0 happens to be valid :-p, the server side creates a file. When you close it, that file stays around as zero length. By sending -1, the old server will error out and never create a file. -- Steve receive V2 + check V2 read MAGIC_NUMBER\00 send V2 +--- receive V2 check V2 send cpus,pagesize,option(MSG_TINIT) receive MSG_TINIT ---+ print cpus=XXX print pagesize=XXX understand option send port_array +--MSG_RINIT- receive MSG_RINIT understand port_array send meta data(MSG_SENDMETA) receive MSG_SENDMETA + record meta data (snip) send a message to finish sending meta data | (MSG_FINMETA) receive MSG_FINMETA -+ read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- send MSG_CLOSE receive MSG_CLOSE ---+ close(socket fd)close(socket fd) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
