I've been working with AS3 sockets, and I noticed that small packets are 'Nagled' when sent. I tried to find a way to set NoDelay for the socket, but I didn't find a clue even in the documentation. Is there another way to turn Nagle'a algorithm off in AS3 TCP sockets?
You can tell Flash to send out the data through the socket using the Flush method on the socket Object.
Flushes any accumulated data in the socket's output buffer.
That said, flash does what it thinks is the better, and may doesn't want to send your data too often. Still, that shouldn't be over few milliseconds.
Related
I want to use a WebRTC data channel to exchange json messages between peers.
Can I safely assume that each json message arrives atomically remotely (not like in TCP where packets may be split or chunked together) or do I need implement something like a length prefix to know where one message ends and another begin?
Using a reliable channel and possibly a tcp turn server, if that's relevant.
Yes, according to the webRTC draft spec, whatever message you send() down a data channel should arrive in a single onmessage callback at the far end.
In real life however, Chrome sometimes calls onmessage with a partial message when it runs out of buffers. If you keep your messages <64k this seems not to happen.
I am currently working on a web service in Go that essentially takes a request and sends back JSON, rather typical. However, this particular JSON takes 10+ seconds to actually complete and return. Because I am also making a website that depends on the JSON, and the JSON contents are subject to change, I implemented a route that quickly generates and returns (potentially updated or new) names as placeholders that would get replaced later by real values that correspond to the names. The whole idea behind that is the website would connect to the service, get back JSON almost immediately to populate a table, then wait until the actual data to fill in came back from the service.
This is where I encounter an issue, potentially because I am newish to Go and don't understand its vast libraries completely. The previous method that I used to send JSON back through the HTTP requests was ResponseWriter.Write(theJSON). However, Write() terminates the response, so the website would have to continually ping the service which could now and will be disastrous in the future
So, I am seeking some industry knowledge into my issue. Can HTTP connections be continuous like that, where data is sent piecewise through the same http request? Is that even a computationally or security smart feature, or are there better ways to do what I am proposing? Finally, does Go even support a feature like that, and how would I asynchronously handle it for performance optimization?
For the record, my website is using React.js.
i would use https websockets to achieve this effect rather than a long persisting tcp.con or even in addition to this. see the golang.org/x/net/websocket package from the go developers or the excellent http://www.gorillatoolkit.org/pkg/websocket from gorilla web toolkit for use details. You might use padding and smaller subunits to allow interruption and restart of submission // or a kind of diff protocol to rewrite previously submitted JSON. i found websocket pretty stable even with small connection breakdowns.
Go does have a keep alive ability net.TCPConn's SetKeepAlive
kaConn, _ := tcpkeepalive.EnableKeepAlive(conn)
kaConn.SetKeepAliveIdle(30*time.Second)
kaConn.SetKeepAliveCount(4)
kaConn.SetKeepAliveInterval(5*time.Second)
Code from felixqe
You can use restapi as webservice and can sent data as a json.SO you can continously sent data over a communication channel.
I'm a beginner iOS developer, and I'm trying to build a CRM system to learn the different aspects of developing.
I have a question regarding the preferred way to connect to an external SQL-server. I'm using Karl Krafts' Obj-C MySQL Connector by the way.
Right now I init the Database-controller (which in turn creates, then idles the connection to the server) object in my app delegate (didFinishLaunchingWithOptions), and that gives me some unwanted side-effects.. The screen is black a long time at startup if connection to the DB is slow, and sometimes the app is "too fast" and the query is trying to execute before the connection has been fully established - resulting in an exception being thrown.
The behavior I want (and guess is the preferred) is that the GUI loads up first, and then the initialization of the DB-controller and connection is established in a background thread - updating the GUI when the data has been acquired.
How would I achieve this? I have tried a number of different ways i've come across in my research, dispatch_queues and initing it straight from the viewDidLoad etc, but none give me the desired "GUI then data"-effect.
Also, would it be preferred to have an idling connection during the session of the program - or should each query 'connect - do its thing - disconnect'?
Regards, Christopher
Commandment One: don't do networking on the main thread - it's reserved for the UI. Else your app will have a laggy and frozen UI.
Commandment Two: instead of a lot of sequential synchronous calls, use asynchronous calls (GCD, background threads, etc.), events and callbacks. Cocoa (Touch) is designed with this in mind, so it's easy to do.
Commandment Three: if you launch something automatically, let it be launched when the app is fully ready. Let the call to the web service be the last one in application:didFinishLaunchingWithOptions:. Even better, let the user have the possibility to initiate the login via a user action, i. e. by pressing a "Login" button.
Commandment Four: read the first three Commandment again and keep them in mind. Practice them until you know them well.
Using Flex Builder 4.5 with rails running on localhost on a brand new MacBook Air. Using curl, the response time of the server of a read is around 200-300ms. When I use HTTPService, from send() to result received is between 1-5 seconds for less than ten lines of XML received from the server. If I use the browser to render the URL, it matches curl, ie it is instantaneous, I'm not waiting for the XML to render.
The number is the same for debug/non-debug mode. The HTTPService is called after creation complete, so the GUI is done. After data is received, the rest of my algorithms are completing under 20ms in the application.
Is this time expected, or am I doing something wrong, or have something configured incorrectly?
What you've described sounds like HTTPService isn't setting the TCP_NODELAY socket option (setsockopt(3)) on its sockets before sending a request. From my Linux tcp(7):
TCP_NODELAY
If set, disable the Nagle algorithm. This means that
segments are always sent as soon as possible, even if
there is only a small amount of data. When not set,
data is buffered until there is a sufficient amount to
send out, thereby avoiding the frequent sending of
small packets, which results in poor utilization of
the network. This option is overridden by TCP_CORK;
however, setting this option forces an explicit flush
of pending output, even if TCP_CORK is currently set.
Perhaps your platform has another way you can ask to disable Nagle's algorithm for a specific connection.
To expand on sarnold's answer, what you need to do is add the following line:
<socket-tcp-no-delay-enabled>true</socket-tcp-no-delay-enabled>
Using Action Script 3 in Flex Builder 3.
When handling a SOCKET_DATA event, I occasionally, seemingly at random, get an "Error #2030: End of file was encountered." when calling socket.readInt(). I'm confused as to what this error means, since I'm not reading a file? I'm a little unfamilier with sockets. Thanks.
An end-of-file error typically means the other side of the socket has closed their connection, IIRC.
The reason it's end-of-file is that at a very low level within a program, a file on the disk and a socket are both represented with a number -- a file descriptor -- that the OS translates into the object representing a file or socket or pipe or whatever.
Usually, you can avoid this kind of error by checking if you just read in an EOF. If you did read an EOF, and you try reading from the socket/file again, then you will get an EOF error.
Update: According to the ActionScript 9.0 documentation, you do indeed get a close event if the other end closes the socket.
When reading off a socket, that is closed, you will get: Error #2002: Operation attempted on invalid socket.
End-of-file errors typically occur on any bytestreams, if you read more bytes than available. This is the case for files, sockets, etc. In the case of flash, it occurs when reading from a Socket or a ByteArray and maybe even in other cases.
TCP/IP is package based, but emulates a stream, thus you can only read the data off the stream, that was already sent to you with TCP packages. Check Socket::bytesAvailable to find out, how many bytes are currently available. Always keep in mind, that the data you write to the socket in one operation, may arrive in multiple packages, each very probably causing flash player to trigger socketData events.