Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I am wondering whether the transmission time of a TCP socket configurable. I am sending a TCP packet with payload of size 19 bytes and the transmission time seems to be 1 sec approx. Can this be brought down or does one have to just accept whatever it is?
How exactly do you calculate this time? I hope you're not comparing the time of two different computers, since their clocks are probably not identical.
However, having said this, you're probably suffering from the Nagle algorithm where the connection waits to transmit data to see if there's more to batch together. You can turn this off by setting the Tcp options.
http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.nodelay.aspx
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed yesterday.
Improve this question
I were making event based project, but when I tried to choose between TCP and UDP I got lost.
Connecting using TCP sounds good, but performance might be affected due to buffering.
On the other hand, UDP is more suitable in terms of performance and context, but some requests require guarantees and/or connection.
So, TCP or UDP?
Data Size < 2KB
Tested with TCP - a bit laggy on activity spikes with macroses, UDP is not implemented yet, but I usually have spikes of packet loss when working with it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
The Sip call drops after 30 seconds, but it doesn't always happen. I think it's because of NAT timeout. Am I correct? Or is it something else?
It's because 30 seconds is the timeout value for SIP transactions and it's probable that the ACK request, which completes a call INVITE transaction, is not getting through.
As to why the ACK request is not getting through there are a number of possibilities but it's unlikely to be NAT. If it was a NAT issue then the initial INVITE request is unlikely to have reached the callee SIP device.
A common issue can be SIP Application Layer Gateways (ALG) built into home routers. They will often apply very crude text replacements on private IP addresses in SIP packets and this can be enough to break SIP transaction matching logic. Check the specifications on your router model and if it has a SIP ALG turn it off.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've read a lot of books and articles mentioning data streams, which I've used mostly in Java, and none of them really mention exactly what a data stream is under the hood. Is it data aligned in memory consecutively as bytes?
Bonus question: What about a socket? How is it represented in memory exactly and how is it connected to a hardware input/output?
A Java stream is an abstraction: just something that you can read from or write to. It is usually backed by an external resource such as a file or a socket. For gory details of each stream, and there are dozens, see the source code. The only two streams that really accord with your description 'sequence of memory addresses' are ByteArrayInputStream and ByteArrayOutputStream.
A socket is an endpoint of a communication. Internally it is a data structure in the kernel, and it is 'connected' to a network protocol stack which in turn is connected to one or more network interface cards (NICs).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
At work, we are speaking about the interest to have 10 or 30 connections simultanly to a usenet provider.
Some guys said it change nothing because the 10 or 30 threads will take all the bandwidth available, so the download time will be the same.
Another guys said it change something because you can download more file at the same time.
Someone have a GOOD explanation to this problematic ? :)
Thanks ^^
The NNTP protocol has a lot of latency, so running multiple simultaneous connections can improve the speed of actions, particularly if there's a lot of back and forth with the server. (More recent versions of the protocol have support for streaming, but not many clients or servers know about this yet.) 10-30 sounds like overkill to me, though; usually you get the benefits of avoiding latency with 4-8 connections.
The best thing to do would be to test a variety of different numbers of connections for the exact thing you're trying to do and see which one is faster, though. It's going to depend on what types of actions you're taking.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am looking to write a simple client/server utilizing TCP sockets. Any ideas how to do network programming in Go?
Go has fine support for networking.
For a server, the easiest thing to do is have your main() start a tcp accept loop and spawn a goroutine to handle each request.
The first go software I wrote was a memcached server. You may want to check out gomemcached for an idea of how to get started on servers.
Clients shouldn't be particularly harder. In many cases, it may make the most sense to have a shared client with goroutines for inbound communication much like I use in gomemcached for communicating with the actual storage layer.
Of course, this isn't the only way. Perhaps you'll find something better as you experiment.