Random832 wrote:
Isn't this technically the same problem as pressing ctrl-d at a terminal
- it's not _really_ the end of the input (you can continue reading
after), but it sends the program something it will interpret as such?
Yes. There's no concept of "closing the connection" with UDP,
becau
On Tue, Sep 22, 2015, at 15:45, James Harris wrote:
> "Dennis Lee Bieber" wrote in message
> news:mailman.12.1442794762.28679.python-l...@python.org...
> > On Sun, 20 Sep 2015 23:36:30 +0100, "James Harris"
> > declaimed the following:
> >>Receiving no bytes is taken as indicating the end of the
"Marko Rauhamaa" wrote in message
news:8737y6cgp6@elektro.pacujo.net...
"James Harris" :
I agree with what you say. A zero-length UDP datagram should be
possible and not indicate end of input but is that guaranteed and
portable?
The zero-length payload size shouldn't be an issue, but UDP
"James Harris" :
> I agree with what you say. A zero-length UDP datagram should be
> possible and not indicate end of input but is that guaranteed and
> portable?
The zero-length payload size shouldn't be an issue, but UDP doesn't make
any guarantees about delivering the message. Your UDP applica
"Akira Li" <4kir4...@gmail.com> wrote in message
news:mailman.18.1442804862.28679.python-l...@python.org...
"James Harris" writes:
...
There are a few things and more crop up as time goes on. For example,
over TCP it would be helpful to have a function to receive a specific
number of bytes or o
"Dennis Lee Bieber" wrote in message
news:mailman.12.1442794762.28679.python-l...@python.org...
On Sun, 20 Sep 2015 23:36:30 +0100, "James Harris"
declaimed the following:
There are a few things and more crop up as time goes on. For example,
over TCP it would be helpful to have a function t
On Mon, 2015-09-21, Chris Angelico wrote:
> On Mon, Sep 21, 2015 at 6:38 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa wrote:
You can read a full buffer even if you have a variable-length length
encoding.
>>>
>>> Not sure what you m
On Mon, 2015-09-21, Cameron Simpson wrote:
> On 21Sep2015 10:34, Chris Angelico wrote:
>>If you're going to add sequencing and acknowledgements to UDP,
>>wouldn't it be easier to use TCP and simply prefix every message with
>>a two-byte length?
>
> Frankly, often yes. That's what I do. (different
On 21Sep2015 18:07, Chris Angelico wrote:
On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa wrote:
Chris Angelico :
On Mon, Sep 21, 2015 at 4:27 PM, Cameron Simpson wrote:
For sizes below 128, one byte of length. For sizes 128-16383, two bytes. And
so on. Compact yet unbounded.
[...]
It's
On 2015-09-21 09:47, Marko Rauhamaa wrote:
Michael Ströder :
Marko Rauhamaa wrote:
Michael Ströder :
Marko Rauhamaa wrote:
I recommend using socket.TCP_CORK with socket.TCP_NODELAY where they
are available (Linux).
If these options are not available are both option constants also not
avai
On Mon, 2015-09-21, Dennis Lee Bieber wrote:
> On Sun, 20 Sep 2015 23:36:30 +0100, "James Harris"
> declaimed the following:
...
>>I thought UDP would deliver (or drop) a whole datagram but cannot find
>>anything in the Python documentaiton to guarantee that. In fact
>>documentation for the sen
On Mon, Sep 21, 2015 at 6:38 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa wrote:
>>> You can read a full buffer even if you have a variable-length length
>>> encoding.
>>
>> Not sure what you mean there. Unless you can absolutely guarantee that
Chris Angelico :
> On Mon, Sep 21, 2015 at 6:38 PM, Marko Rauhamaa wrote:
>> Only one reader can read a socket safely at any given time so mutual
>> exclusion is needed.
>>
>> If you read "too much," the excess can be put in the application's read
>> buffer where it is available for whoever wants
Michael Ströder :
> Marko Rauhamaa wrote:
>> Michael Ströder :
>>
>>> Marko Rauhamaa wrote:
I recommend using socket.TCP_CORK with socket.TCP_NODELAY where they
are available (Linux).
>>>
>>> If these options are not available are both option constants also not
>>> available? Or does th
Marko Rauhamaa :
> Chris Angelico :
>
>> On Mon, Sep 21, 2015 at 6:38 PM, Marko Rauhamaa wrote:
>>> Only one reader can read a socket safely at any given time so mutual
>>> exclusion is needed.
>>>
>>> If you read "too much," the excess can be put in the application's read
>>> buffer where it is
On Mon, Sep 21, 2015 at 6:38 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa wrote:
>>> You can read a full buffer even if you have a variable-length length
>>> encoding.
>>
>> Not sure what you mean there. Unless you can absolutely guarantee that
Chris Angelico :
> On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa wrote:
>> You can read a full buffer even if you have a variable-length length
>> encoding.
>
> Not sure what you mean there. Unless you can absolutely guarantee that
> you didn't read too much, or can absolutely guarantee that yo
Marko Rauhamaa wrote:
> Michael Ströder :
>
>> Marko Rauhamaa wrote:
>>> I recommend using socket.TCP_CORK with socket.TCP_NODELAY where they
>>> are available (Linux).
>>
>> If these options are not available are both option constants also not
>> available? Or does the implementation have to look
On Mon, Sep 21, 2015 at 5:59 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Mon, Sep 21, 2015 at 4:27 PM, Cameron Simpson wrote:
>>> For sizes below 128, one byte of length. For sizes 128-16383, two bytes. And
>>> so on. Compact yet unbounded.
>>
>> [...]
>>
>> It's generally a lot faster t
Michael Ströder :
> Marko Rauhamaa wrote:
>> I recommend using socket.TCP_CORK with socket.TCP_NODELAY where they
>> are available (Linux).
>
> If these options are not available are both option constants also not
> available? Or does the implementation have to look into sys.platform?
>>> impo
Chris Angelico :
> On Mon, Sep 21, 2015 at 4:27 PM, Cameron Simpson wrote:
>> For sizes below 128, one byte of length. For sizes 128-16383, two bytes. And
>> so on. Compact yet unbounded.
>
> [...]
>
> It's generally a lot faster to do a read(2) than a loop with any
> number of read(1), and you g
On Mon, Sep 21, 2015 at 4:27 PM, Cameron Simpson wrote:
> I don't like embedding arbitrary size limits in protocols or data formats if
> I can easily avoid it. So (for my home grown binary protocols) I encode
> unsigned integers as big endian octets with the top bit meaning "another
> octet follow
Marko Rauhamaa wrote:
> I recommend using socket.TCP_CORK with socket.TCP_NODELAY where they are
> available (Linux).
If these options are not available are both option constants also not
available? Or does the implementation have to look into sys.platform?
Ciao, Michael.
--
https://mail.python
Chris Angelico :
> On Mon, Sep 21, 2015 at 2:39 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> If you write a packet of data, then write another one, and another,
>>> and another, and another, without waiting for responses, Nagling
>>> should combine them automatically. [...]
>>
>> Unfortun
On 21Sep2015 12:40, Chris Angelico wrote:
On Mon, Sep 21, 2015 at 11:55 AM, Cameron Simpson wrote:
On 21Sep2015 10:34, Chris Angelico wrote:
If you're going to add sequencing and acknowledgements to UDP,
wouldn't it be easier to use TCP and simply prefix every message with
a two-byte length?
Dennis Lee Bieber wrote:
worst case: each TCP packet is broken up to fit Hollerith
cards;
Or printed on strips of paper and tied to pigeons:
https://en.wikipedia.org/wiki/IP_over_Avian_Carriers
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Sep 21, 2015 at 2:39 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Mon, Sep 21, 2015 at 11:55 AM, Cameron Simpson wrote:
>>> Another nice thing about TCP is that wil a little effort you get to
>>> pack multiple data packets (or partial data packets) into a network
>>> packet, etc.
Chris Angelico :
> On Mon, Sep 21, 2015 at 11:55 AM, Cameron Simpson wrote:
>> Another nice thing about TCP is that wil a little effort you get to
>> pack multiple data packets (or partial data packets) into a network
>> packet, etc.
>
> Emphatically - a little effort sometimes, and other times n
"James Harris" writes:
...
> There are a few things and more crop up as time goes on. For example,
> over TCP it would be helpful to have a function to receive a specific
> number of bytes or one to read bytes until reaching a certain
> delimiter such as newline or zero or space etc.
The answer
On Mon, Sep 21, 2015 at 11:55 AM, Cameron Simpson wrote:
> On 21Sep2015 10:34, Chris Angelico wrote:
>>
>> If you're going to add sequencing and acknowledgements to UDP,
>> wouldn't it be easier to use TCP and simply prefix every message with
>> a two-byte length?
>
>
> Frankly, often yes. That's
On 21Sep2015 10:34, Chris Angelico wrote:
If you're going to add sequencing and acknowledgements to UDP,
wouldn't it be easier to use TCP and simply prefix every message with
a two-byte length?
Frankly, often yes. That's what I do. (different length encoding, but
otherwise...)
UDP's neat if
On Mon, Sep 21, 2015 at 10:19 AM, Dennis Lee Bieber
wrote:
> Even if the IP layer has to fragment a UDP packet to meet limits of
> the
> transport media, it should put them back together on the other end before
> passing it up to the UDP layer. To my knowledge, UDP does not have a size
>
"Akira Li" <4kir4...@gmail.com> wrote in message
news:mailman.37.1442754893.21674.python-l...@python.org...
"James Harris" writes:
I guess there have been many attempts to make socket IO easier to
handle and a good number of those have been in Python.
The trouble with trying to improve someth
"James Harris" writes:
> I guess there have been many attempts to make socket IO easier to
> handle and a good number of those have been in Python.
>
> The trouble with trying to improve something which is already well
> designed (and conciously left as is) is that the so-called improvement
> can
I guess there have been many attempts to make socket IO easier to handle
and a good number of those have been in Python.
The trouble with trying to improve something which is already well
designed (and conciously left as is) is that the so-called improvement
can become much more complex and ov
35 matches
Mail list logo
