parsing packets
Aman Nijhawan
amannijhawan at gmail.com
Sun Jul 10 22:08:45 EDT 2011
Are you sending binary data if so you can use the struct module to pack,
unpack and interpret binary data http://docs.python.org/library/struct.html
,
You will have to design the header scheme yourself you can
either embed length in the packets or try to use a carefully selected
delimiter character .
Thanks
Aman
On Sun, Jul 10, 2011 at 5:31 PM, <python-list-request at python.org> wrote:
> Send Python-list mailing list submissions to
> python-list at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
> python-list-request at python.org
>
> You can reach the person managing the list at
> python-list-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
>
> Today's Topics:
>
> 1. Re: parsing packets (Michael Hrivnak)
> 2. Re: Wgy isn't there a good RAD Gui tool fo python (CM)
> 3. Re: Function docstring as a local variable (Ben Finney)
> 4. Re: Function docstring as a local variable (Tim Johnson)
> 5. Re: Function docstring as a local variable (Chris Rebert)
> 6. Re: Function docstring as a local variable (Chris Rebert)
> 7. Re: Function docstring as a local variable (Tim Johnson)
> 8. Re: Function docstring as a local variable (Corey Richardson)
> 9. Re: Virtual functions are virtually invisible! (Michael Hrivnak)
>
>
> ---------- Forwarded message ----------
> From: Michael Hrivnak <mhrivnak at hrivnak.org>
> To: tyler at tysdomain.com
> Date: Sun, 10 Jul 2011 19:33:38 -0400
> Subject: Re: parsing packets
> In order to find the end of the packet, include a field that is the
> packet length. This is what IP packets do to find the end of their
> header.
>
> http://en.wikipedia.org/wiki/IPv4#Header
>
> And the TCP header (see "data offset") does the same:
>
>
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure
>
> Of course in both cases they are specifying the header length, not
> including a data payload. However, it sounds like you might not have
> a payload, so your entire packet might consist of header-like data.
>
> Michael
>
>
> On Sun, Jul 10, 2011 at 4:59 PM, Littlefield, Tyler <tyler at tysdomain.com>
> wrote:
> > Hello all:
> > I'm working on a server that will need to parse packets sent from a
> client,
> > and construct it's own packets.
> > The setup is something like this: the first two bytes is the type of the
> > packet.
> > So, lets say we have a packet set to connect. There are two types of
> connect
> > packet: a auth packet and a connect packet.
> > The connect packet then has two bytes with the type, another byte that
> notes
> > that it is a connect packet, and 4 bytes that contains the version of the
> > client.
> > The auth packet has the two bytes that tells what packet it is, one byte
> > denoting that it is an auth packet, then the username, a NULL character,
> and
> > a password and a NULL character.
> >
> > With all of this said, I'm kind of curious how I would 1) parse out
> > something like this (I am using twisted, so it'll just be passed to my
> > Receive function), and how I get the length of the packet with multiple
> NULL
> > values. I'm also looking to build a packet and send it back out, is there
> > something that will allow me to designate two bytes, set individual bits,
> > then put it altogether in a packet to be sent out?
> >
> > --
> >
> > Take care,
> > Ty
> > my website:
> > http://tds-solutions.net
> > my blog:
> > http://tds-solutions.net/blog
> > skype: st8amnd127
> > My programs don't have bugs; they're randomly added features!
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
>
>
> ---------- Forwarded message ----------
> From: CM <cmpython at gmail.com>
> To: python-list at python.org
> Date: Sun, 10 Jul 2011 16:49:51 -0700 (PDT)
> Subject: Re: Wgy isn't there a good RAD Gui tool fo python
> On Jul 10, 6:50 pm, Ivan Kljaic <iklj... at gmail.com> wrote:
> > Ok Guys. I know that most of us have been expiriencing the need for a
> > nice Gui builder tool for RAD and most of us have been googling for it
> > a lot of times. But seriously. Why is the not even one single RAD tool
> > for Python. I mean what happened to boa constructor that it stopped
> > developing. I simply do not see any reasons why there isn't anything.
> > Please help me understand it. Any insights?
>
> Just because Boa Constructor stopped (or lengthily paused?)
> development
> doesn't mean it doesn't exist. It does, and (at least on Windows), it
> is, IMO, really good. So why don't you use it?
>
> Che
>
>
>
>
> ---------- Forwarded message ----------
> From: Ben Finney <ben+python at benfinney.id.au>
> To: python-list at python.org
> Date: Mon, 11 Jul 2011 09:48:46 +1000
> Subject: Re: Function docstring as a local variable
> "Colin J. Williams" <cjw at ncf.ca> writes:
>
> > On 10-Jul-11 13:44 PM, rantingrick wrote:
> > > On Jul 10, 12:41 pm, Tim Johnson<t... at johnsons-web.com> wrote:
> > >> It possible for a function to print it's own docstring?
> > >
> > > def f():
> > > """docstring"""
> > > print "docstring"
> >
> > Try:
> >
> > def f():
> > ds= """docstring"""
> > print ds
>
> The OP wants the function to print its own docstring, which your example
> does not do. You've defined a function with an empty docstring.
>
> >>> def foo():
> ... ds = "The Larch"
> ... print ds
> ...
> >>> foo.__doc__
> >>>
>
> --
> \ “Firmness in decision is often merely a form of stupidity. It |
> `\ indicates an inability to think the same thing out twice.” |
> _o__) —Henry L. Mencken |
> Ben Finney
>
>
>
> ---------- Forwarded message ----------
> From: Tim Johnson <tim at johnsons-web.com>
> To: python-list at python.org
> Date: Sun, 10 Jul 2011 16:00:54 -0800
> Subject: Re: Function docstring as a local variable
> * Carl Banks <pavlovevidence at gmail.com> [110710 15:18]:
> > On Sunday, July 10, 2011 3:50:18 PM UTC-7, Tim Johnson wrote:
> > > Here's a related question:
> > > I can get the docstring for an imported module:
> > > >>> import tmpl as foo
> > > >>> print(foo.__doc__)
> > > Python templating features
> > >
> > > Author - tim at akwebsoft dot com
> > >
> > > ## Is it possible to get the module docstring
> > > ## from the module itself?
> >
> >
> > print __doc__
> Thanks Carl.
>
> Where is general documentation on the subject of variables
> beginning with 2 underscores?
>
> I'm presuming the key phrase is 'builtin variables'. I'm searching
> too ...
>
> --
> Tim
> tim at johnsons-web dot com or akwebsoft dot com
> http://www.akwebsoft.com
>
>
>
> ---------- Forwarded message ----------
> From: Chris Rebert <clp2 at rebertia.com>
> To: Tim Johnson <tim at johnsons-web.com>
> Date: Sun, 10 Jul 2011 17:09:27 -0700
> Subject: Re: Function docstring as a local variable
> On Sun, Jul 10, 2011 at 5:00 PM, Tim Johnson <tim at johnsons-web.com> wrote:
> > * Carl Banks <pavlovevidence at gmail.com> [110710 15:18]:
> >> On Sunday, July 10, 2011 3:50:18 PM UTC-7, Tim Johnson wrote:
> <snip>
> >> > ## Is it possible to get the module docstring
> >> > ## from the module itself?
> >>
> >> print __doc__
> > Thanks Carl.
> >
> > Where is general documentation on the subject of variables
> > beginning with 2 underscores?
> >
> > I'm presuming the key phrase is 'builtin variables'. I'm searching
> > too ...
>
> I've never heard that phrase used to describe __doc__ or its friends.
>
> Look in the "underscore" section of the documentation index:
> http://docs.python.org/genindex-_.html
>
> Cheers,
> Chris
>
>
>
> ---------- Forwarded message ----------
> From: Chris Rebert <clp2 at rebertia.com>
> To: Corey Richardson <kb1pkl at aim.com>
> Date: Sun, 10 Jul 2011 17:16:23 -0700
> Subject: Re: Function docstring as a local variable
> On Sun, Jul 10, 2011 at 4:06 PM, Corey Richardson <kb1pkl at aim.com> wrote:
> > Excerpts from Carl Banks's message of Sun Jul 10 18:59:02 -0400 2011:
> >> print __doc__
> >>
> >
> > Python 2.7.1 (r271:86832, Jul 8 2011, 22:48:46)
> > [GCC 4.4.5] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> def foo():
> > ... "Docstring"
> > ... print __doc__
> > ...
> >>>> foo()
> > None
> >>>>
> >
> >
> > What does yours do?
>
> The question Carl's code was in answer to was, slightly paraphrased:
> "Is it possible to get a *module*'s docstring from within the module
> itself?"
> The question had nothing to do with *function* docstrings.
>
> The interactive interpreter environment also isn't quite a true
> module, so you can't give it a docstring or really test the relevant
> feature there. Try this instead:
> $ cat test.py
> """I am the docstring of the `test` module!"""
>
> print("This module's docstring is:", __doc__)
> $ python test.py
> This module's docstring is: I am the docstring of the `test` module!
> $
>
> Cheers,
> Chris
> --
> http://rebertia.com
>
>
>
> ---------- Forwarded message ----------
> From: Tim Johnson <tim at johnsons-web.com>
> To: Python ML <python-list at python.org>
> Date: Sun, 10 Jul 2011 16:21:59 -0800
> Subject: Re: Function docstring as a local variable
> * Chris Rebert <clp2 at rebertia.com> [110710 16:14]:
> > >
> > > Where is general documentation on the subject of variables
> > > beginning with 2 underscores?
> >
> > I've never heard that phrase used to describe __doc__ or its friends.
> :) That why I wasn't satified with my search results.
> > Look in the "underscore" section of the documentation index:
> > http://docs.python.org/genindex-_.html
> And that is what I was looking for.
> thanks
> --
> Tim
> tim at johnsons-web dot com or akwebsoft dot com
> http://www.akwebsoft.com
>
>
>
> ---------- Forwarded message ----------
> From: Corey Richardson <kb1pkl at aim.com>
> To: python-list <python-list at python.org>
> Date: Sun, 10 Jul 2011 20:26:02 -0400
> Subject: Re: Function docstring as a local variable
> Excerpts from Chris Rebert's message of Sun Jul 10 20:16:23 -0400 2011:
> > The question Carl's code was in answer to was, slightly paraphrased:
> > "Is it possible to get a *module*'s docstring from within the module
> > itself?"
> > The question had nothing to do with *function* docstrings.
> >
>
> Ah. My bad, thank you for clarifying.
> --
> Corey Richardson
> "Those who deny freedom to others, deserve it not for themselves"
> -- Abraham Lincoln
>
>
> ---------- Forwarded message ----------
> From: Michael Hrivnak <mhrivnak at hrivnak.org>
> To: rantingrick <rantingrick at gmail.com>
> Date: Sun, 10 Jul 2011 20:31:49 -0400
> Subject: Re: Virtual functions are virtually invisible!
> It sounds to me like you need a better IDE, better documentation,
> and/or better code to work on and use. I don't understand why it's
> difficult to look at a derived class as see what methods are
> overridden. If you are working on the code, it is quite obvious what
> methods exist in the base class. If you're not willing to get an
> intimate understanding of how the base class works, you probably
> shouldn't be working on the subclass. If the base class is difficult
> to understand, it's probably poorly written and/or poorly documented.
> Neither of these problems should be solved by adding complexity to the
> language. Referencing the Zen of Python: "If the implementation is
> hard to explain, it's a bad idea."
>
> If you are just using a library but not developing it, why does it
> matter what methods are overridden? As long as class "Derived"
> behaves the way it is documented, who cares how it got that way or
> what is going on behind the scenes? If you need to read the code to
> figure out how it works, then it's just poorly documented.
>
> Django is a great example, because it is very well documented. Most
> users have little idea of what base classes are involved and what
> features are overridden, because it doesn't matter when you are just
> using the library. When you need to write your own subclass of a
> django class, then it might matter, and you should see my first
> paragraph.
>
> And in terms of "non-starters", any "Pythonista" who isn't willing to
> adhere to the style guide and document their code wouldn't work on my
> team for very long, if at all. There is just no excuse for that.
>
> Michael
>
> On Sun, Jul 10, 2011 at 1:15 PM, rantingrick <rantingrick at gmail.com>
> wrote:
> > On Jul 4, 3:43 am, Gregory Ewing <greg.ew... at canterbury.ac.nz> wrote:
> >> rantingrick wrote:
> >> > what concerns me is the fact that virtual methods in derived
> >> > classes just blend in to the crowd.
> >> > I think we really need some
> >> > sort of visual cue in the form of forced syntactical notation (just
> >> > like the special method underscores).
> >>
> >> If you're suggesting that it should be impossible to override
> >> a method unless it is specially marked somehow in the base
> >> class, I think that would be a bad idea.
> >
> > Sorry i did explain properly... No NOT marked in the BASE class but
> > marked in the DERIVED class! My concerns are from a readability
> > standpoint. Here's a naive example...
> >
> > class Top(object):
> > def __init__(self):
> > pass
> > def m1(self):
> > """overide"""
> > return True
> > def m2(self):
> > print 'm2'
> >
> >
> > def Derived(Top):
> > def __init__(self):
> > Top.__init__(self)
> > def <overide>m1(self):
> > return False
> >
> > My argument is this...
> >
> > """If class "Derived" exists in another module the reader has no
> > idea which methods where clobbered and which were not WITHOUT being
> > intimate with the entire code base."""
> >
> > I suggest we solve this dilemma by forcing a syntax "tag" when
> > declaring clobbering virtual functions. And if someone forgets to
> > include the tag python would throw an exception. This has the effect
> > of making the code MUCH easier to follow by the human readers. And it
> > put NO constraints on the API. Also it has the added effect of warning
> > unsuspecting programmers of name clashes that would otherwise not
> > produce an error.
> >
> >> One of the principles behind the design of Eiffel is that
> >> classes should *always* be open to modification in any way
> >> by a subclass. The reason is that the author of a class
> >> library can't anticipate all the ways people might want to
> >> use it. Consequently Eiffel has no equivalent of C++'s
> >> "private" declaration -- everything is at most "protected".
> >> It also has no equivalent of Java's "final".
> >
> > Exactly! We should never put limits on what methods CAN be virtual.
> > However, we CAN enforce a syntax that removes ambiguity from the
> > equation.
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Aman Nijhawan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110710/0d5db5ac/attachment-0001.html>
More information about the Python-list
mailing list