search for: reply

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...

...ump show on both sides when you ping? ping -c 1 guest (10.100.100.74) -> external (10.91.73.252) (these are on the same subnet) guest: 15:29:51.342545 IP 10.100.100.74 > 10.91.73.252: ICMP echo request, id 64778, seq 1, length 64 15:29:51.342716 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778, seq 1, length 64 15:29:51.342734 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778, seq 1, length 64 15:29:51.342799 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778, seq 1, length 64 15:29:51.342835 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778,...

...ump show on both sides when you ping? ping -c 1 guest (10.100.100.74) -> external (10.91.73.252) (these are on the same subnet) guest: 15:29:51.342545 IP 10.100.100.74 > 10.91.73.252: ICMP echo request, id 64778, seq 1, length 64 15:29:51.342716 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778, seq 1, length 64 15:29:51.342734 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778, seq 1, length 64 15:29:51.342799 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778, seq 1, length 64 15:29:51.342835 IP 10.91.73.252 > 10.100.100.74: ICMP echo reply, id 64778,...

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 dir...

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? > > > > -hpa > > Hi Peter, > > My assumption is that having a specific and adequate "reply-t...

...gins/nbd/nbd.c @@ -1,5 +1,5 @@ /* nbdkit - * Copyright (C) 2017-2018 Red Hat Inc. + * Copyright (C) 2017-2019 Red Hat Inc. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are @@ -453,6 +453,158 @@ nbd_reply (struct handle *h, int fd) return err ? -1 : 0; } +static int +nbd_newstyle_recv_option_reply (struct handle *h, uint32_t option, + struct fixed_new_option_reply *reply, + char **payload) +{ + char *buffer; + + if (payload) + *...

...O 6 -#define NBD_OPT_GO 7 +#define NBD_OPT_EXPORT_NAME 1 +#define NBD_OPT_ABORT 2 +#define NBD_OPT_LIST 3 +#define NBD_OPT_STARTTLS 5 +#define NBD_OPT_INFO 6 +#define NBD_OPT_GO 7 +#define NBD_OPT_STRUCTURED_REPLY 8 extern const char *name_of_nbd_rep (int); #define NBD_REP_ACK 1 @@ -144,15 +145,49 @@ struct request { uint32_t count; /* Request length. */ } __attribute__((packed)); -/* Reply (server -> client). */ -struct reply { - uint32_t magic; /* NBD_RE...

...ort a status extent with a size larger than 32-bits, in some cases even if the client's request was for smaller than 32-bits (such as when it is known that the entire image is not sparse). Thus, the wording chosen here is careful to permit a server to use either flavor status chunk type in its reply, and clients requesting extended headers must be prepared for both reply types. Second, when structured replies are active, clients have to deal with the difference between 16- and 20-byte headers of simple vs. structured replies, which impacts performance if the client must perform multiple sysca...

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 more indirection where sbuf is malloc'd; I'm...

...com 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:> ping 10.1.1.1 Reply from 10.1.1.1: bytes=32 time<1ms TTL=127 Reply from 10.1.1.1: bytes=32 time<1ms TTL=127 Reply from 10.1.1.1: bytes=32 time<1ms TTL=127 Reply from 10.1.1.1: bytes=32 time=-29815ms TTL=127 Reply from 10.1.1.1: bytes=32 time<1ms...

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 ent...

...uot; 0.103118 send_to_all: SETINFO driver.version.internal "1.56" 0.103131 send_to_all: SETINFO driver.name "blazer_ser" 0.103141 Trying megatec protocol... 0.103687 send: 'Q1' 1.105456 read: timeout 1.105823 blazer_status: short reply 1.106058 Status read 1 failed 1.106825 send: 'Q1' 2.108171 read: timeout 2.108295 blazer_status: short reply 2.108338 Status read 2 failed 2.108638 send: 'Q1' 3.109987 read: timeout 3.110242 blazer_status: short reply 3.1103...

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...

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...

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 change the default back. > > > > > > Would people object to trying it? > > > > > > -hpa > > > > Hi Peter, > > > > My assumption is that...

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...

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 poster, tha...

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

...match device 0.020136 Device matches 0.020655 failed to claim USB device: could not claim interface 0: Device or resource busy 0.021625 detached kernel driver from USB device... 0.022676 Trying megatec protocol... 0.025291 send: Q1 0.153928 read: N 0.154751 blazer_status: short reply 0.155441 Status read 1 failed 0.156783 send: Q1 0.286922 read: N 0.287605 blazer_status: short reply 0.288335 Status read 2 failed 0.289796 send: Q1 0.419969 read: N 0.420052 blazer_status: short reply 0.420081 Status read 3 failed 0.420107 Trying mustek protocol......