search for: replis

This was v3 patch 2/22, reworked to address the confusion about how a structured reply header is read in two pieces before getting to the payload portion. I'm still working on rebasing the rest of my v3 series (patches 1, 3-22) from other comments given, but this seemed independent enough that it's worth posting now rather than holding it up for the rest of the series. Eric Blake (4):

^C --- 10.100.100.74 ping statistics --- 1 packets transmitted, 1 received, +63 duplicates, +1 errors, 0% packet loss, time 0ms rtt min/avg/max/mdev =3D 0.263/2.481/4.266/1.147 ms > This ping is external box to guest, > correct? Either direction, external box->guest or guest->external box > Is it the external box that gets duplicates or the guest? > What happens when you ping

^C --- 10.100.100.74 ping statistics --- 1 packets transmitted, 1 received, +63 duplicates, +1 errors, 0% packet loss, time 0ms rtt min/avg/max/mdev =3D 0.263/2.481/4.266/1.147 ms > This ping is external box to guest, > correct? Either direction, external box->guest or guest->external box > Is it the external box that gets duplicates or the guest? > What happens when you ping

On 6/9/23 04:17, Eric Blake wrote: > In order to more easily add a third reply type with an even larger > header, but where the payload will look the same for both structured > and extended replies, it is nicer if simple and structured replies are > nested inside the same layer of sbuf.reply.hdr. Doing this also lets > us add an alias for accessing the cookie directly without

On Mar 14, 2014 3:41 PM, "Ady" <ady-sf at hotmail.com> wrote: > > > > Hi all, > > > > A few years ago, at popular request, I changed the default of the list > > to have a Reply-To: pointing at the list. I personally find it very > > annoying, and I would like to change the default back. > > > > Would people object to trying it? >

The NBD spec was recently patched (nbd.git commit 7827f3ae and friends) to require NBD_OPT_GO for baseline interoperability, with the aim of fewer servers and clients falling back to NBD_OPT_EXPORT_NAME. And since nbdkit as server recently started supporting NBD_OPT_GO (commit f7dd9799), our nbd client as plugin should take advantage of it. This patch is a prerequisite to teaching the nbd plugin

This is about the simplest implementation of NBD Structured Replies (SR) that we can do right now. It accepts NBD_OPT_STRUCTURED_REPLIES when negotiated by the client, but only sends back the simplest possible SR when required to by NBD_CMD_READ. The rest of the time it will send back simple replies as before. We do not modify the plugin API so plugins are unable to send complex SRs. Also we

Add a new negotiation feature where the client and server agree to use larger packet headers on every packet sent during transmission phase. This has two purposes: first, it makes it possible to perform operations like trim, write zeroes, and block status on more than 2^32 bytes in a single command. For NBD_CMD_READ, replies are still implicitly capped by the maximum block payload limits

I'm still playing with ideas on how to split rstate from wstate (so that we can send a request without waiting for POLLIN to complete a pending reply), but this is some preliminary refactoring I found useful. I also fixed a couple of bugs while in the area (already pushed). There's a question of whether we want nbd_handle to be nearly 5k, or if we should instead keep it small and add one

Hi, I have a Dell PowerEdge 1950 with two NICs Broadcom NetXtreme II BCM5708 1000Base-T. I installed CentOS 5.1 and Xen 3.0.3 (RPM). One of my virtual machines has Windows 2003 Server. In this virtual machine my NICs appears like "Realtek RTL8139 Family PCI Fast Ethernet NIC". The problem is that when I ping to other machines sometimes the reply time value is very high: C:>

Could whomever is in charge of the lartc mailing list please change it to add the header: Reply-To: lartc@mailman.ds9a.nl Every other list I''m on is setup so that by default replies will go to the list. When replying to lartc emails I notice myself and others constantly forgetting this list does not behave like the rest, and that we have to either do a reply-to-all, or manually enter in

No progress has been made: cable is UPS - PC 6 - 3 7 - 5 9 - 2 for ./blazer_ser -DDDDD -a infosec 0.000000 send_to_all: SETINFO driver.parameter.port "/dev/ttyS1" 0.000323 debug level is '5' 0.103068 send_to_all: SETINFO device.type "ups" 0.103104 send_to_all: SETINFO driver.version "2.7.3" 0.103118 send_to_all: SETINFO

When processing a server reply within the REPLY subgroup, we will often hit a situation where recv() requires us to block until the next NotifyRead. But since NotifyRead is the only permitted external action while in this group, we are effectively blocking CmdIssue and NotifyWrite events from happening until the server finishes the in-progress reply, even though those events have no strict

Updated based on other changes that have happened in the meantime: - rely more on cleanup.h (throughout) - split structured read for easier review (patch 2 and 3 were combined in v1) - rely on nbdkit not leaking a server's partial answer (patch 3) - add tests (patch 5) - other bug fixes I found while testing it - drop EOVERFLOW patch for now; it will be separate once upstream NBD protocol

No need to have each state recompute which reply is current. This also consolidates the logic when a reply has an unexpected handle - previously, we failed for structured (even though the length makes it easy to recover) and passed for simple (even though there is nothing on the wire to state if this response is associated with NBD_CMD_READ if we did not negotiate structured replies, which would

Op 2014-03-14 om 16:02 schreef Gene Cumm: > On Mar 14, 2014 3:41 PM, "Ady" <ady-sf at hotmail.com> wrote: > > > > > > > Hi all, > > > > > > A few years ago, at popular request, I changed the default of the list > > > to have a Reply-To: pointing at the list. I personally find it very > > > annoying, and I would like to

Instead of repeating a check for valid reply headers in each sub-state machine, let's have a common helper function do all the work. Additionally, a central location will make it easier to uniformly capture any NBD_REP_ERR message payloads. --- generator/generator | 8 +-- generator/states-newstyle-opt-go.c | 40 +++----------

Hi, is there a chance to alter the list behaviour to not use the sender address of a posting in the reply-to field but dovecot at dovecot.org instead? That way one has to either use "reply to all" in the MUA or manually enter dovecot at dovecot.org in any replies. And a "reply to all" duplicates postings because the posting once goes to the list and once to the original

Hi all, A few years ago, at popular request, I changed the default of the list to have a Reply-To: pointing at the list. I personally find it very annoying, and I would like to change the default back. Would people object to trying it? -hpa

Hello i need your help regarding the following issue : i have a hero touch ups from infosec. it is connected via USB to a raspberry pi 3. i?ve configure ups.conf file as below [HERO] driver = blazer_usb vendorid = 0665 productid = 5161 either with port = auto or port = /dev/hidraw0 or port = /dev/ttySo the connection never works i get the