search for: sent_request

...ate(struct net *net, vsk->listener = NULL; INIT_LIST_HEAD(&vsk->pending_links); INIT_LIST_HEAD(&vsk->accept_queue); + INIT_LIST_HEAD(&vsk->dgram_skb); /* TODO free list entries on shutdown and limit list size or timeout somehow? */ vsk->rejected = false; vsk->sent_request = false; vsk->ignore_connecting_rst = false; -- 2.4.1

...being not set. But the chrome complains otherwise. Given below is the chrome error log and the part of the wirehark capture (after decryption). Can someone , help me identify the problem? session event = type = connecting - description = Connecting... test_wss_ast.html:39 session event = type = sent_request - description = REGISTER request successfully sent test_wss_ast.html:39 WebSocket connection to 'wss://nicta-vm1.cloudapp.net:8089/ws' failed: A server must not mask any frames that it sends to the client. SIPml-api.js:3 __tsip_transport_ws_onerror SIPml-api.js:1 __tsip_transport_ws_onclose...

...> virtio_transport_stream_is_active(struct vsock_sock *vsk); diff --git > a/include/net/af_vsock.h b/include/net/af_vsock.h index > 2ca67d048de4..4b5d16840fd4 100644 > --- a/include/net/af_vsock.h > +++ b/include/net/af_vsock.h > @@ -65,6 +65,11 @@ struct vsock_sock { > bool sent_request; > bool ignore_connecting_rst; > > + /* Protected by lock_sock(sk) */ > + u64 buffer_size; > + u64 buffer_min_size; > + u64 buffer_max_size; > + > /* Private to transport. */ > void *trans; > }; > @@ -140,18 +145,12 @@ struct vsock_transport { > struct...

...iwat(struct vsock_sock *vsk); bool virtio_transport_stream_is_active(struct vsock_sock *vsk); diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h index 2ca67d048de4..86f8f463e01a 100644 --- a/include/net/af_vsock.h +++ b/include/net/af_vsock.h @@ -65,6 +65,11 @@ struct vsock_sock { bool sent_request; bool ignore_connecting_rst; + /* Protected by lock_sock(sk) */ + u64 buffer_size; + u64 buffer_min_size; + u64 buffer_max_size; + /* Private to transport. */ void *trans; }; @@ -140,18 +145,11 @@ struct vsock_transport { struct vsock_transport_send_notify_data *); int (*notify_send_p...

...iwat(struct vsock_sock *vsk); bool virtio_transport_stream_is_active(struct vsock_sock *vsk); diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h index 2ca67d048de4..4b5d16840fd4 100644 --- a/include/net/af_vsock.h +++ b/include/net/af_vsock.h @@ -65,6 +65,11 @@ struct vsock_sock { bool sent_request; bool ignore_connecting_rst; + /* Protected by lock_sock(sk) */ + u64 buffer_size; + u64 buffer_min_size; + u64 buffer_max_size; + /* Private to transport. */ void *trans; }; @@ -140,18 +145,12 @@ struct vsock_transport { struct vsock_transport_send_notify_data *); int (*notify_send_p...

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1:

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

This patch series adds a virtio transport for AF_VSOCK (net/vmw_vsock/). AF_VSOCK is designed for communication between virtual machines and hypervisors. It is currently only implemented for VMware's VMCI transport. This series implements the proposed virtio-vsock device specification from here: http://comments.gmane.org/gmane.comp.emulators.virtio.devel/855 Most of the work was done by

This patch series adds a virtio transport for AF_VSOCK (net/vmw_vsock/). AF_VSOCK is designed for communication between virtual machines and hypervisors. It is currently only implemented for VMware's VMCI transport. This series implements the proposed virtio-vsock device specification from here: http://comments.gmane.org/gmane.comp.emulators.virtio.devel/855 Most of the work was done by