i am a bit stuck and need some hints please.
My ISP seems to throttle single connections to 400 kbps no matter if i use VPN/ssh tunnel/proxy or direct connect. For file transfer its not a problem, i can use lftp with multiple connections which gets me to 1 Gbps in up or down.
I have a few vps and a dedicated server which i would like to use as a tunnel to overcome this limitation. I have already tried wireguard/openvpn/cloak/shadowsocks. Is there anything else what creates maybe multiple tcp or udp connections to get things going?
Thanks,
Dennis
Related
I am using mininet for emulation of a network. My network has a delay of 3000ms(linear topology of 3 switches).When I tried to do iperf I got Connection failed : No route to host error in client. After a lot of time with the help of internet i came to know that this is happening because of large delay of network which causes ACK packet delayed. Thus thia ACK pcket for SYN will client after timeout. So I want to modify this timeout value. How can I do this. I am using iperf2 and ubuntu18.04. ( I think using iperf3 this is possible with --connect-timeout nms)
iperf 2 doesn't support --connect-timeouts. The preferred way to control that is via the operating system itself, e.g. syn retries. More on that here. We don't think we should be messing with TCP fundamentals directly as we want to separate testing from the things under test.
As an aside, iperf 2.0.14 has a --connect-only option which can be used to measure the TCP 3WHS performance. We also added a --connect-retries for application level retries.
Bob
I'm using uIP along with mbed TLS to run a simple web server on a microcontroller, and host an HTTPS page.
The problem is: my chip only has enough RAM to handle one TLS connection at a time, but Firefox (and Chrome) tries to open multiple connections at once to load the images on the page. If I tell uIP to abort or close additional connections, Firefox assumes an error and gives up loading the rest of the page.
I can tell uIP to limit the total connections to 1, and in that case it just drops new SYN packets if there is already a connection. This actually works, as Firefox will wait and try again until the page is fully loaded. I can't use this a solution however, since I do need to allow more than 1 TCP connection total in order to handle other types of connections (I can serve a regular HTTP web page at the same time, for example). If I could tell uIP to limit connections on a specific port to 1 at a time, that may solve the problem, but I don't think uIP has that capability. I also don't see a way to force uIP to drop certain packets.
I've looked all over the web, but I can't find any information on running a web server using just one TCP connection at a time.
Does anyone have any ideas?
Thanks!
Marlon
Just ignore the SSL connection until you are ready to process it. Browsers should tolerate this.
I'm not sure if this is the correct place to ask, so forgive me if it isn't.
I'm writing computer monitoring software that needs to connect to a server. The server may send out relatively urgent messages, such as sound or cancel an alarm, and the client may send out data about the computer, such as screenshots. The data that the client sends isn't too critical on timing, but shouldn't be more than a two minutes late.
It is essential to the software that portforwarding need not be set up, and it is assumed that the internet connection will be done through a wireless router that has NAT almost all the time.
My idea is to have a TCP connection initiated from the client, and use that to transfer data. Ideally, I would have no data being sent when it is not needed, but I believe this to be impossible. Would sending the equivalent of a ping every now and again keep the connection alive, and what sort of bandwidth would it use if this program was running all the time on the computer? In addition, would it be possible to reduce the header size for these keep-alives?
Before I start designing the communication and programming, is this plan for connection flawed? Are there better alternatives?
Thanks!
1) You do not need to send 'ping' data to keep the connection alive, the TCP stack does this automatically; one reason for sending 'ping' data would be to detect a connection close on the client side - typically you only find out something has gone wrong when you try and read/write from the socket. There may be a way to change various time-outs so you can detect this condition faster.
2) In general while TCP provides a stream-oriented error free channel, it makes no guarantees about timeliness, if you are using it on the internet it is even more unpredictable.
3) For applications such as this (I hope you are making it for ethical purposes) - I would tend to use TCP, since you don't want a situation where the client receives a packet to raise an alarm but misses that one that turns it off again.
Unfortunately I don't know much networks. I am writing a program that has two versions. A server version and a client version. Lets assume that the client versions are installed on, say 20 PCs that are connected to the server over ethernet. The client versions needs to CONSTANTLY get some data from the server. The data is kind of serial. I wanted to know a way to broadcast the data that gets updated every second and make it available to all the other PCs in the network. Could I use the HTTP Port for this?, like writing the data to an HTML page or something? or Is there a better port or method for doing this?
Any ideas will be greatly appreciated.
This sounds like a pretty straightforward application of TCP sockets. The server would be set up to "listen" on a particular port (you pick the port number, say 12345), and each client would make a TCP connection to the server on that port.
Whenever the server has data to send, it would send it once to each connected client. This could mean that the server sends the data up to 20 times on different sockets, but that's fine. The client would read the data from its connected socket to the server.
There are other alternatives, such as UDP or even UDP multicast, but these usually end up being a lot more complicated because UDP doesn't guarantee that packets always arrive at the destination (and they may even be duplicated or out of order). TCP ensures that the data you send either arrives complete in the correct order, or doesn't arrive at all (in that case the connection would be dropped).
An example of this sort of multiple TCP connection is VNC:
VNC is widely used in educational contexts, for example to allow a distributed group of students simultaneously to view a computer screen being manipulated by an instructor, or to allow the instructor to take control of the students' computers to provide assistance.
There are many ways. you can choose any of them but i think, document below will help you a lot.
Multicast over TCP/IP HOWTO:
http://www.ibiblio.org/pub/Linux/docs/howto/other-formats/html_single/Multicast-HOWTO.html#sect-trans-prots
I'm new to the concept of nw-sniffing. < so , i'll try to describe the problem with the best terms i know >
In an organisation , there are 30 computers connected to a server. And as users of these systems browse the Internet , packets are sent to the outside nw via this server.. i want to write an application that runs in this server , that sniffs these packets , reads the Http requests , the IP addresses to analyse these packets and block those found objectionable.
Where to begin ? pl help. Thanks in advance.
The best place to begin would definately be theory. Look up how IP packets are built-up, what a HTTP packet looks like and how networks are structured at a low level. There's alot worth learning.
As far as tools for learning go, I'd highly recommend Wireshark. Allow you to perform DPI (Deep Packet Inspection) and get used to what you're after.
A common method of DPI is to use a SOCKS server or similar proxy through which all traffic is filtered.
DPI has downsides. It will affect your network and, if naively implemented, can easily add a single point of failure.