My IDE of choice is Intellij IDEA, but I’ve evaluated Eclipse several times, so I know how it works. I also knew that Eclipse CDT is a one of the best free IDEs for C development available, so I chose it as my C IDE. On my desktop PC I use Windows, but software I was modifying is Unix-only. When I’ve finished writing code I’ve uploaded it using FTP on Linux host (more on that later), and launched make. Of course I had compilation errors, but after some editing and uploading I finally got binary executable. The program is a network proxy. I’ve started it, sent some messages through it, and, as I expected, it was not working in a right way. I had to debug it to know why.

With Java it is very easy to debug programs remotelly. You just ask IDE to do a remote debug, IDE will display to you what command-line options you should add to java executable, then you just type host and port, and that’s it. All debugging takes place in JVM, and your IDE is a debugging front-end. Easy and straightforward.

Not like this with Eclipse CDT. I’ve opened “Debug configurations” window, and saw “C/C++ Remote Application” option. I chose this option, but I found myself confused with fields I had to specify: location of executable and location of debugger. Even after I’ve downloaded executable from Linux to Windows, I couldn’t start remote debugging. So I decided to abandon this attempt for a while and try manual debugging with GDB.

This debugger was surprisingly easy for me to learn. It is much less cryptic than other Unix tools. Just a dozen of simple and memorable commands which you can print on one small sheet of paper for reference. Using GDB I quickly found my errors. The only inconvenience is that you have to switch between terminal window where GDB is running and Eclipse CDT window where code is. Also I still had an impression that remote debugging is actually possible from Eclpse CDT, so I decided to get it working, or at least to have an explanation why it is not possible.

And that’s that I’ve discovered after some long investigation. When C guys say “remote debug” they mean something very-very different from what Java guys mean. To remotelly debug C program you should link it with small chunk of code, which is able to do basic control of program execution (setting breakpoints, pausing-resuming, …) and basic program state examination (memory, stack frames, registers). This chunk of code is called “target side“. It will communicate with main part of a debugger which will be located on another machine. Debugger should be able to access an image of a program with all it’s symbols. This symbolic info allows debugger to perform all high-level debugging job, like showing contents of local variables, execution of code in line-by-line mode, setting breakpoint on function. This part of a debugger is called “symbol side+UI“. When you perform a local debug both sides are in a same gdb process. You can also avoid linking with target size code by launching gdbserver which will attach to any process on a host. There is no official name for a protocol between target side and symbol side, so I’ll call it Remote Serial Protocol. It can work over serial cable or over TCP/IP.

So, difference between remote debugging in Java and remote debugging in C is that in case of Java target side and symbol side work on the same machine as program being debugged, and UI is on remote machine. In case of C only target side is located with program being debugged, and symbol side together with UI is on remote machine. Such approach allows debugging programs in cases where normal gdb will not work in local mode. For example, if you have a program for embedded device, which doesn’t have enough memory for full GDB.

But I want to remotelly debug programs with GDB in Java style. C guys will call it “remote UI for GDB”. And I believe that this is possible. Then you debug a program locally with Eclipse CDT, it creates a process for gdb, and intercepts it’s input and output. Then it says to GDB that instead of human-oriented command language it will use for communication a special machine-oriented language called MI (“machine interface”), which is easier to parse. So in order to use Eclipse CDT as a remote UI for GDB I should just launch GDB remotelly and remotelly attach to it’s input and output. I’ll try to make a plugin for Eclipse using my knowledge of Java, because a bunch of questions on StackOverflow shows that such capability is demanded.

Some links:

http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html#Remote-Protocol

http://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI.html#GDB_002fMI

http://sourceware.org/gdb/current/onlinedocs/gdbint/Overall-Structure.html#Overall-Structure

http://dev.eclipse.org/mhonarc/lists/dsdp-tm-dev/msg01369.html

http://wiki.eclipse.org/TM_and_RSE_FAQ#How_can_I_do_Remote_Debugging_with_CDT.3F

http://www.ibm.com/developerworks/library/os-eclipse-cdt-debug2/index.html

1. After installation of a platform I knew I need cabal. Haskell wiki says it is there, but I didn’t knew where to look. Finally I’ve found it: in Haskell Platform directory there is a place with path lib/extralibs/bin. It seems that I need to read full platform documentation before starting using it
2. OK, with cabal I’ve tried to install snap framework. It stumbled on ghc-paths component, complaing that it “cannot configure”. I’ve checked and found that this component is used to find path where Haskell Platform is installed. I’ve checked my path and there were an entry for Haskell bin directory. A mystery. I’ve tried to run ghc from that command line (Far Manager, actually) which I’ve used to start cabal, and no, ghc was not found. I’ve typed ‘path’, and an entry for Haskell Platform was missing. I’ve remembered that command line was started before I’ve installed Haskell Platform, so changes in system path were not seen. Restarting command line solved that problem
3. Next package I’ve tried to install was hxt. It complained that it cannot determine version of ghc. It took me a while to figure out that command line should be started with admin rights.
4. I’ve tried to create a blank project with snap. Just create a folder and type ‘snap init’. Then I’ve tried to build that project with cabal. Oops, “can’t parse name”. It took me some time to guess that it doesn’t like symbol ‘-’ in the name of that folder

So far so good.

I’m calling software module a “framework” if it is built with “Inversion of control” pattern. You provide callbacks, and framework invokes them according to it’s specification. Sometimes you can manage frameworks, but you cannot customize it beyond certain degree. Your code is not active, it is either passive or reactive.

Event-driven programming model is a one example of framework architecture. Software containers is another example.

Now you can see why I call SIP stacks which implement JAIN SIP API or SIP Servlets API as frameworks. They read data from network, handle them and then invoke a supplied listener (either SipServlet or SipListener). This invocation takes place in a thread of a SIP stack, so if you should not block it. JAIN SIP API has dispatch of incoming traffic based on local endpoint, and SIP Servlets API has method-based dispatch, but this is not a very significant difference.

Why SIP stacks are implemented as frameworks? To answer this, let’s imagine a stack which is implemented as a library. So, you create a socket, read from it, and then pass a byte array to stack for handling. SIP stack will return a result to you in functional style:

ByteBuffer data = ByteBuffer.allocate(MAX_MESSAGE);

SocketAddress remote = channel.receive(data);

SipResult result = stack.handle(data, remote);

Since there are many possible results of handling SIP messages, now you should analyze the result and dispatch according to it: was the message parsed correctly or not, was it request or response, was it a retransmission or not, and many other choices. If request was parsed correctly but has some mandatory headers missing, then result should contain error response which you can send through stack object. Such dispatch code is large, and should be written once because it’s behaviour is well specified in RFC 3261. This is a first reason why stacks are implemented as frameworks: they include common dispach code.

A second reason is that application programmers often afraid of working with threads and sockets directly. They consider that to be “system-level” code, which should be hidden from them. Developers of SIP stacks should bother about performance, race conditions and other complex stuff.

Thus, SIP stacks are frameworks, and I think that this is a right way. By the way, most HTTP stacks are also frameworks.

Now I will explain why I think that JAIN SIP API and SIP Servlets API are not perfect frameworks.

JAIN SIP API has a single callback called SipListener. It has only two methods for processing incoming messages: processRequest() and processResponse(). Thus, SIP stack does very little dispatch for you. If you are doing a stateless proxy, you’ll have very simple logic there. But for UA and statefull proxy there will be one large “if” statement. It could be implemented in different ways. One way is to map transactions and dialog on your application contexts. In this case you’ll have to look up into maps. Another way is to bind application contexts to transactions and dialogs using setApplicationData() method. In this case you’ll need to invoke getApplicationData() then cast it to your application context. When you have your application context you have additional dispatch. JAIN SIP API is flexible here, but this dispatching code is reusable, thus it should be written once. This dispatch code makes a better protocol framework on top of framework provided by SipListener.

A better protocol framework should have the following capabilities:

• ServerTransactionListener, which can be provided to specific server transaction. This listener will be notified when transaction terminates, when final response retransmission timeout happens, and when CANCEL is received
• ClientTransactionListener, which can be provided to specific client transaction. This listener will be notified when response is received
• DialogListener, which can be provided to specific dialog. This listener will be notified when dialog has been forked and when dialog has been terminated
• ServerListener, which is invoked for incoming requests. There should be one “global”  listener, and there could be specific listener for each dialog.

Such protocol framework will allow you to write applications with much less dispatch code.

Most of that is also true for SIP Servlets API. You have to extract attributes from SipSession and dispatch your execution based on them. However, they have some things better:

• You can specify which servlet will handle which SipSession. Unfortunatelly, servlets are stateless.
• Method-based dispatch is provided by SipServlet class

Thus, SIP Servlets API doesn’t provide a powerful protocol framework. Instead, they provide application framework: you can compose servlets, you have listener for various things such as binding attributes to sessions.

I hope I have explained why I consider SIP stacks to implement “framework” architecture. I also hope I have explaided why I think that it could be a better frameworks.

And, finally, what I’m calling an “application server” ? An application server:

• Is a server for some protocol
• Is implemented as a framework for this protocol
• Is implemented as component container

Thus, SIP Servlets API and JAIN SLEE are describing application server, but JAIN SIP API is not.

ptrace

A system call of System V and BSD (also exists in Linux) which may be used by one process “to observe and control the execution of another process”. Available commands include reading and writing a memory of the process (used for setting breakpoints), reading CPU registers, intercepting signals sent to the process, intercepting system calls made by the process. Intercepting is done by stopping a traced process and sending a signal SIGCHILD to process which requested the tracing. Observer then may request information about stopped process and may continue its execution.

strace

A Linux utility which is used to trace system calls and signals. Uses ptrace() system call

ktrace/ktruss/kdump

A system call of BSD unixes which traces system calls and signals of specified process and writes the data in specified file. Since there is no context switch between processes, a tracing is faster. Trace data are not human-readable. A ktrace is also a name of command-line utility for unixes of BSD family which does a process tracing by invoking ktrace(). kdump is an utility which reads tracing info written into file by ktrace() and prints this info in human-readable form. ktruss is another command-line utility for BSD-derived unixes which traces system calls and signals for some process by using ktrace() system call. It prints tracing info in human-readable form on console.

systrace

A facility of some BSD unixes which is intended to restrict certain system calls done by some process. In simplest case can be used just to trace those calls. Implemented as pseudo-device “/dev/systrace”. System call ioctl() is used to perform actions such as attaching to process or permit to do a system call. System call read() on systrace device will block until some traced process will perform a system call. Systrace is also a name of command-line utility which uses systrace facility.

ltrace

A command-line utility which traces system calls and calls to functions of dynamically linked libraries. System calls are traced using ptrace(). Library calls are traced by analyzing symbol table of ELF file, calculating addresses and placing breakpoints for every library call using ptrace(). When breakpoint hits a stack trace of the process is obtained (using ptrace()) and compared with breakpoint table to get function name.

dtrace

Tracing facility originally developed for Solaris and later moved to other Unixes. It consists of core, “probe providers” which register with core, and “probe consumers” which are user-level processes like ‘dtrace’ command-line tool. Consumers can express an interest in some probe by asking a core to enable it. Core, in turn, uses provider to obtain and address.

JAIN SIP API focuses on implementation simplicity. It is not a stack, but a Stack SDK. If you need to quickly implement some well-known call-flow, JAIN SIP API is a bad choice. But if you want to implement some new SIP feature, then JAIN SIP API may come handy.

SIP Servlets API focuses on developer’s productivity and enforces implementation to be very powerful, because it is not an API for SIP stack, but API provided by application server. It is especially suited for well-known areas of SIP. However, it doesn’t allow you to do something unusual. Other minor drawbacks are bloat and manual contextualization.

By the way, there is an interesting move by company called OpenCloud. They support two APIs: one is JAIN SIP API, just a little bit extended, and another is called “EasySIP“, which is a complete rip-off of SIP Servlets API. They have introduced separate classes for incoming and outgoing requests and responses.

While both APIs could be used with some effort, I’m not satisfied with them. I want an API which:

• Has stack management methods much more powerful then in JAIN SIP API. It should be possible to add/remove local endpoints while stack is running. A listener should receive a reference local endpoint with incoming requests.
• Has much better built-in support for “protocol context”. For incoming ACK and PRACK it should be possible to get a response it acknowledges. For incoming CANCEL it should be possible to get a request it cancels
• Has syntax separated from behaviour.
• Will produce compilation errors if trying to respond on incoming ACK or CANCEL, to respond on outgoing request, to acknowledge outgoing response, to cancel incoming response.
• Is a protocol framework. It should be possible to specify listener for any particular client transaction, server transaction and dialog.

Such API will be powerfull enough so it will provide the same level of developer’s productivity as SIP Servlets API. But it will also be extensible, and could be used in any type of applications, not only on server side.

SipServlet interface

First obvious problem of SIP Servlets API is that it is an extension of Generic Servlets API. The cornerstone class of Generic Servlets API is called Servlet, and has only three methods: init(), service() and destroy(). In my opinion, the main problem here is that this class is essentially a too generic framework. Behaviour of container is always protocol-dependent, so servlets are also protocol-dependant. Still, everybody are forced to use this narrow interface for interaction. Are there any convergent servlets which handle several protocols through their service() method ? No, there are convergent applications instead. I think that service() method should be removed from Servlet class. Instead, all concrete servlets would have their own service() method, accepting protocol-specific requests and responses.

I understand that most people don’t bother with problem of downcasting request and response in service() method, so it is not a big deal. I just don’t like it working in this way.

Applications always do some dispatch for incoming messages, so APIs provide some dispatch out-of-box to help application developers. Unlike JAIN SIP API, which has dispatch based on local endpoint and on message type (request/response), SIP Servlets API have built-in dispatch based on request method and response status code. I think that this approach is more useful for applications.

Syntax

Next bad thing in SIP Servlets API is an existence of SipServletMessage interface. It’s exactly the same case as with JAIN SIP API: this abstraction is not used by anyone. Yes, it is good that signatures of methods in SipServletRequest and SipServletResponse are the same, but nothing will break if these signatures would differ. Authors of SIP Servlet API have ignored the lesson of HTTP Servlets API, which doesn’t have common interface. I understand that HTTP is much more assymmetric then SIP, so in HTTP servlets people are reading headers of requests and writing headers and body to responses, so syntaxic similarity is not related to behaviour. But I still don’t see how syntaxic symmetry of SIP requests and responses could be used in practice.

Syntax part of SIP Servlets API is much smaller and simpler then of JAIN SIP API. Obtaining header will return you a string, adding or changing a header will also accept value as string. Additional parsing is supported only for address headers.

Behaviour

SipServletMessage interface includes not only syntax-related methods but also method send(). Message is a nice context for method send(), because it is the message which should be sent. The fact that method send() belongs to SipServletMessage interface shows that SIP Servlets API doesn’t strive for separation of syntax and behaviour. SipServletMessage is not just a header, start line and body, but it is a gateway to SIP stack, hiding transactions, dialogs and all other protocol layers. This means that you can’t just “forward” incoming message, because it can’t be separated from all internal state. Instead you should either create a new message and manually copy all necessary data from original message into new message, or use hacks provided by API (like proxyTo() or createRequest() method which accepts original request). Thus the amount of interfaces in API is low, but the amount of behavioural methods is large, and their semantics is more complex. However, as long as “message=syntax+state” approach was selected, all methods which implement SIP behaviour are also belong to SipServletRequest or SipServletResponse classes, so message is a context for an action. Such approach is easy to understand by beginners.

Another problem of method send() is that compiler will not complain if you’ll try to invoke it for incoming message. Of course SIP stack will not send such message, you’ll get IllegalStateException in runtime. Thus, SIP Servlets API is not designed to use type system for preventing errors.  A correct solution would be to have separate classes like IncomingRequest, OutgoingRequest, IncomingResponse, OutgoingResponse. There are other behaviour-related methods which could be moved to specific classes instead of throwing an IllegalStateException: createCancel(), createResponse(), createAck(). Some special requests (like ACK and CANCEL) could also be represented by specific classes which would not have methods createResponse().

SIP Servlets API provide large application framework, with different listeners. However, it doesn’t provide a powerfull protocol framework. Instead, you have a SipSession which represents either dialog or proxying session. This SipSession is used for two purposes. First, as a factory for in-dialog requests. Second, as a storage for application context. This means that for every incoming subsequent message an application should restore its context from SipSession object. Such manual contextualization is not a very convenient thing to program, but it allows application server to be distributed and fault-tolerant. Ability to set a servlet which will handle the session can’t be considered as a protocol framework, since that servlet also can’t have its own context and should contextualize itself from SipSession. A little bit more information is given in subsequent post.

Conclusion

SIP Servlets API is not an API for SIP stack. Instead it is an API for application server which means that it tries to be as complete as possible and it is not designed to be extensible. Container should provide all nesessary functionality, and servlets should just contain business logic needed to handle incoming messages. This makes it attactive to beginners who enjoy it’s protocol power. This API will not allow you to violate SIP rules, however it is usually done by throwing exceptions in runtime. Protocol framework is absent, all you have is a SipSession to store and restore your context.

Next article will compare both APIs, will discuss lots of general API-related stuff and will propose better solutions.

This is a first article of the series which will study popular Java APIs for SIP: JAIN SIP API and SIP Servlets API. My intention is to analyze what is good and what is bad, and why it is so. These articles represent my personal opinion, however I’m not just going to tag things as “good” or “bad”. Instead, I’ll try to explain why I like or dislike something. The study will focus on technical aspects of APIs. Since I’m not satisfied with current state of affairs, I also want to propose a better API. Yes, the purpose of this study is to justify the need for another SIP API, because I believe that API is very important.

I don’t think that a long intoduction is needed, so let’s start with JAIN SIP API.

JAIN SIP API

This API is quite curious because it is very maximalistic in implementation of SIP syntax and quite minimalistic in implementation of SIP behaviour. I have a very strong impression that the author (exactly as I did) at the beginning has focused his attention on syntax believing that parser is the only re-usable part of SIP, and all messaging  scenarios are so volatile that they should be implemented in applications. A version of 1.0 of this API covers only a parser together with a stateless sender/receiver. However, in version 1.2 this API also covers some re-usable behavioural layers, such as transaction layer and dialog layer.

Syntax representation

A noticeable feature of JAIN SIP API is that you can work with protocol syntax without a running stack. You just need to obtain a specific factory and then create syntax objects through it.

There are two interfaces which represent two kinds of SIP messages: Request and Response. These interfaces have a common parent interface Message, which contains common syntax-related functionality. I think that existence of Message interface is a bad thing. Occam’s razor should be applied here: RFC 3261 doesn’t say anything about messages in general, so this abstraction is totally unnecessary. Let’s do a simple check: are there any methods of JAIN SIP API which accept Message as parameter or return it as a result? No. This is an example of OOP people to apply abstraction everywhere, and also an implementation detail showing though an API.

Interfaces Request/Message/Response provide methods for obtaining/adding/removing header fields, modify start line and obtaining/setting body. These methods are defined quite well, except of methods for obtaining headers. Instead of single method which accepts header name and returns abstract Header which should be downcasted, I propose having specific methods for each known header, for examle getViaHeader(). This will make code more clear and will involve compiler into error checking.

JAIN SIP API strives to have an interface for every documented SIP header. Interfaces for all headers are descendants of Header interface. This interface has getName() method, which is correct in my opinion, meaning that header name defines a format for header value. Unfortunatelly, there is no getValue() method, such method is available only for ExtensionHeader. This is bad, because for some headers (like ‘Content-Type’, for example) it is often needed to obtain whole value instead of accessing it’s parts.

I don’t have very much to say about Address, URI and SipURI. They are OK.

As you can see, I’m quite satisfied with syntax part of JAIN SIP API. These objects are just data structures reflecting syntax structure of SIP messages.

Stack management: SipStack, SipProvider and ListeningPoint

SIP stack is managed through interface SipStack. Besides lifecycle methods start() and stop(), this interface also has factory methods for ListeningPoints and for SipProviders.These two classes are then supplied to methods add()/remove() to define which network endpoints will be served by which provider.

ListeningPoint is a combo-class for an InetSocketAddress and a String which specifies a name of a transport protocol. This class could be avoided at all. In all methods where ListeningPoint is passed as a parameter it could be replaced with combo of  InetSocketAddress and String. There is a method that returns ListeningPoints, but it can be very well replaced with two methods: one that returns InetSocketAddresses, and another that returns transports for provided InetSocketAddress. So the only point behind this class is to make argument list shorter. I think that it is better to add one or two methods to an existing class then having another useless class.

Interface SipProvider is used to bind a specific SipListener to a specific network endpoint. Thus, JAIN SIP API can only dispatch incoming traffic based on address where it was received. If you can handle all the traffic by single listener – fine, but you still need to create and maintain separate SipProvider for each local endpoint. SipProviders can be added to SipStack or removed from it only while it is stopped. This means that in order to listen on one more port you need to stop listening on all other ports. Such restriction is a very bad idea.

Another responsibility of SipProvider is to be a factory for transactions and dialogs. This implicitly means that all events for these transactions and dialogs will be handled by the listener associated with SipProvider, and all outgoing messages will be sent from the local endpoint associated with this provider. A third responsibility is to serve as a facility for stateless sending of requests and responses.

I suggest that Occam’s razor should be applied to this interface, because it’s responsibilities are vague. It’s essentially a context for a very few things, which could be provided explicitly. All methods of this class could be moved to SipStack, so setListener() method would accept an InetSocketAddress, factory methods for transactions and dialogs whould accept SipListener, and local endpoint for sending whould be choosen automatically.

Transactions

Client and server transactions are represented by interfaces ClientTransaction and ServerTransaction. These interfaces have common parent interface Transaction, which (very similar to Message) has no apparent use and could also be removed without anybody noticing. ClientTransaction has method for sending request and creating a cancel, ServerTransaction has method for sending responses.

Let’s try to apply Occam’s razor to these classes and see if it is possible to replace them with methods. For ServerTransaction, an answer seems to be no, because sometimes server transactions are created automatically by stack.

Maybe a client transaction can be replaced with method sendStatefully() on SipStack? In case of incoming response or timeout, an application needs a context to handle these events. JAIN SIP API is built in a way that transactions are used as contexts, thus transactions are needed. But, maybe it is possible to replace separate factory method and sending method with just one method, which whould send message statefully and return a transaction object? This whould also eliminate vague problems like: what should stack do if ‘Via’ branch of the request has changed after the creation of transaction? The problem with such apporach is caused by threading issue: an event can happen before a thread which invokes sendStatefully() will retrieve transaction, and this event will be handled by another thread which will not find context for the event. However, this problem can be solved by application providing something as a context instead of re-using transactions for that purpose. Thus, sendStatefully() whould accept a context from application, and use that context in ResponseEvent. Thus, client transactions can be avoided.

In fact, transactions do have some support for  application-provided contexts through methods setApplicationData() and getApplicationData(). They have been introduced as a convenient way to avoid having lookup facilities for context in applications. A good idea, but it is implemented in API in a way that makes application to be written like in BASIC:

10 let transaction=provider.createTransaction(request);

20 transaction.setApplicationData(context);

30 transaction.sendRequest();

instead of single invocation:

stack.sendRequest(request, context);

Since send() is invoked only once, there is no need to have separate setApplicationData() method.

Transactions have getState() method which returns transaction state as defined in RFC. This method is more an implementation detail rather then useful thing. Applications are not really interested in difference between COMPLETED and TERMINATED states. Instead, they are interested in things like canRespond(), canCancel() or requestSent().

So, what exactly are the responsibilities of transaction classes? Implementation details which they expose are not really useful. The answer is that they are more than transactions as they are defined in RFC.

For client transactions method send() includes some functionality which is common for proxies an user agents, such as arranging “Route” headers and determining of remote address. This funcionality in fact belongs to another layer (as described here).

Another purpose of transaction classes is to serve as protocol-level context. For example, it is possible to obtain original request. ClientTransactions has method createCancel(), which should be in MessageFactory.

In my opinion, cancellation in JAIN SIP API is done very badly, in the same BASIC style:

10 Request cancel = clientTran.createCancel();

20 ClientTransaction cancelTran = provider.createTransaction(cancel);

30 cancelTran.sendRequest();

instead of simple:

stack.cancel(request);

which is not a subject to errors which can occur because of thread races. I mean: what will happen if a final response will be received between lines 20 and 30 ? JAIN SIP API doesn’t give you an answer. Since stack is a multithreaded module, sending should be done through “atomic” actions, doing several things at once by implementing internal locking.

Another example of not taking threading issues into account is an existence of factory method for server transactions. I strongly believe that server transactions should be always implicitly created for incoming requests (except ACK, of course). Usefulness of stateless proxy is minimal, so attempt to support it in a way that JAIN SIP API does doesn’t justify the problems it brings. For example, what will happen if a retransmission is received while application has delayed a processing of incoming request ? Yes, a retransmission will be processed, and application will get an exception when it will try to create a server transaction for retransmitted request.

Processing of incoming CANCEL is another weak point of JAIN SIP API. I think that it is a responsibility of stack to discover which server transaction should be cancelled, but JAIN SIP API makes it a work for application. But even if there would be a special CancelServerTransaction with method getCancelledTransaction(), this behaviour whould be plagued with threading issues. Thus, such improvement will be useful only if server transactions are created automatically.

At least two implementations (NIST SIP and SIP from OpenCloud) do recognize that server transactions should be created automatically. NIST SIP creates a hidden “prototype” for a transaction. Stack of OpenCloud introduces a method on transaction which removes it. These are bad hacks, because problem should be fixed on API level.

Transactions have method getDialog() which should return a dialog corresponding to that transaction. First, I don’t see any practical reason for this method. And second, what should this method do in case of dialog forking?

Dialogs

I’m more or less satisfied with implementation of dialogs in JAIN SIP API. There are several problems with them, but these problems are not as bad as in other areas.

Existence of separate factory methods for normal requests and ACK is a bad idea. Method for incrementing local sequence number is a bad idea.

Ability to set application context for dialog through setApplicationData() is a good thing. To have this method here is not as bad as for transactions, since dialogs live longer, so application context may change. Of course, changing application context can lead to complex errors because of threading, but it is still a useful thing.

JAIN SIP API doesn’t describe how stack should behave in case of dialog forking. An instance of Dialog which was created by application will be returned with response from first destination. Responses from other destinations will return other dialogs, but how application will recognize them ? There are no event like “DialogForked” so application will know that new dialog is related to existing one.

Layering

JAIN SIP API is not a truly layered API. By looking at it you may think that Dialog.sendRequest() invokes ClientTransaction.sendRequest() which, in turn, invokes SipProvider.sendRequest(). While first may be true, the second can’t be, because both ClientTransaction.sendRequest() and SipProvider.sendRequest() perform the same actions which may modify the request (by exchanging “Route” header and request-URI if “Route” value doesn’t have “;lr”). Thus it is not possible to built your own transaction layer on top of SipProvider. It is also not possible to build your own dialog layer, because server dialogs should move to CONFIRMED state when succesfull response is sent through server transaction, or to TERMINATED state when unsuccesfull response is sent, but there are no means for your dialog to be notified about that.

SipListener and events

Application is notified about incoming messages and changes in state of objects through SipListener callback interface. There are just two methods for processing incoming messages: processRequest() and processResponse() so its an application job to dispatch a processing based on content of events. An implementation of these methods are usually trees of “if/else” operators which analyze transactions, dialogs and application data. A much better way would be to allow setting specific listeners for particular transactions and dialogs. These specific listeners would easily replace all application-provided contexts and will eliminate any dispatch code in application. Thus by applying IoC principle to full extent it is possible to turn stack into good protocol-based framework. (Update: I’ve explained this in more detail in subsequent post)

Conclusion

Let’s summarize all what I’ve said about JAIN SIP API.

Advantages:

• Syntax objects are separated from the behavioural part
  
• Fairly complete
• Easy to understand and use for simple tasks by developers who like BASIC-style imperative programming
• Has semantics which is close to RFC
• Rather easy to implement
• Since it is not restrictive, it is flexible and extensible
  

Disadvantages:

• Parser for messages is not available
• Stack management is unnesessary complex and restrictive
• Transactions show implementation details rather and badly implement a protocol context
• Doesn’t help with productivity
• Thee ways to send a request. Two ways to send a response.
  
• Is not fully complete. For example, doesn’t cover proxying.
• Doesn’t prevent you from doing mistakes
• Doesn’t allow you to override some layers
  
• It is not a real framework (expanded here)
  
• Has holes in specification
  

Be careful, you have been warned!

In next article I’ll discuss SIP Servlets API.

Both APIs provide only very basic means of header manipulations. Method addHeader() adds a value always to the end of the list, and removeHeader() deletes all the headers with same name. Thus, an iterator provides a very convenient way to do more sophisticated actions, like insterting a header value into the middle of the list or removing a header value from the midde of the list. Without iterators, these actions whould require a combination of several get()/add()/remove() operations, complicating a code.

Unfortunatelly, APIs don’t explicitly specify if add()/remove()/set() operations of iterators should be supported. However, it seems that Sailfin and NIST implementation of JAIN SIP API do support it to some extent. Since both implementations have separate classes handling single-value headers (SIPHeader and SingleLineHeader, respectively) and multiple-value headers (SIPHeaderList and MultiLineHeader, respectively) there are also different classes for the iterators. Implemetation of ListIterator for multi-value headers is easy and straightforward, because both implementations use lists as storage of values and just re-use or wrap ListIterator of Java collection framework. Implementations of ListIterator for single-value header are written manually, and they are not full. In case of Sailfin, methods add(), remove() and set() are not implemented. In case of NIST SIP, methods add() and set() are not implemented.

Another interesting question is what should SIP stacks return if there are no headers with provided name ? To be consistent with other cases, a non-null iterator should be returned, having method next() throwing a NoSuchElementException, and having method add() adding new header to the message. After some header was added, iterator should support both navigation with next() and previous() and modification with remove(), add() and set().

NIST SIP returns iterator over empty LinkedList. This iterator supports all modifier methods, but these modifications will be fake: message will not be modified. Sailfin returns iterator of EMPTY_LIST singleton of java.util.Collections. This iterator doesn’t implement modifiers.

Hey you guys other there! You don’t support corner cases properly. Fix up your code, and don’t forget to give me a credit for finding these bugs (just kidding).

Main problem with basic IO was scalability to number of connections. Operation read() will block until some data will become available. It is not a problem if your program accesses files, because file operations never block for a long time. You are just reading the data until you’ll reach the end of file. Reading after the end of file will immediatelly return with “-1″ bytes read. Another good thing is most programs usually access quite small amount of files. In other words, when working with files it is data who is waiting for program to process it, while program can decide what size of internal buffer to use for processing.

But with networking a model of basic IO is not so convenient. First, read() operation may block an execution thread for a long time. This means that to handle several connections simultaneously you’ll need as many threads as the amount of incoming connections you have. There is a small thing which can help you not to block forewer: you can specify a timeout for socket operations. But it will not solve a scalability problem.

Another problem is related to “message”-based structure of most protocols. Often you don’t know how much data you’ll receive. So, you have to organize your code in a special way:

• Always read data by one byte, then assemble data array from those bytes. Code is simple, but slow.
• Read one byte first, then use available() method to determine if there are more data to read. If there are, then read remaining data using bulk operation. Code is more complex, but faster then previous way.

NIO helps you to deal with both these problems. I’ll explain them in a way which seems to me most logical.

First, NIO introduces “Buffers” which are used to combine data and information used to process it. There are also “Channels” which can read into buffers and write from buffers.

To simplify your “basic IO” code you can just call Channels.newChannel() method for your input stream. The resulting channel will implement read() operation which will either block fill provided ByteBuffer with data and moving position to a place right after last byte. This makes code much more simple.

You can avoid wrapping by creating SocketChannel directly. This will get you almost the same result. It is called “blocking NIO”, and I strongly advise using it in simple cases, when thread blocking is not a problem for you.

The only difference between “blocking NIO” and “NIO wrapped around IO” is that you can’t use socket timeout with SocketChannels. Why ? Read a javadoc for setSocketTimeout(). It says that this timeout is used only by streams. However, you can use a trick to make it working:

SocketChannel socketChannel;

socketChannel.socket().setSocketTimeout(500);

InputStream inStream = socketChannel.socket().getInputStream();

ReadableByteChannel wrappedChannel = Channels.newChannel(inStream);

In this example, reading from socketChannel directly will not be interrupted by timeout, but reading from wrappedChannel will be. To find out why it is so, you can take a look inside Java RT library. Socket timeout is used by OS-specific implementation of SocketInputStream, but is is not used by OS-specific implementation of SocketChannel.

However, NIO has much better things to solve a scalability problem. First, you can put a channel into non-blocking mode. This means that read() operation will return immediatelly if there are no data to read. Thus, you can create a single thread which will check all SocketChannels in cycle and read a data if it is available.

Having a single thread is nice, but if it will spin around read() operation it will waste lots of CPU cycles. To help with the performance NIO has a class called “Selector” which WILL block on non-blocking channels. The difference is that it can monitor any amount of channels, resuming execution when at least one of those channels has some readable data. This idea was copied from Unix, but with one big flaw: Selector can use only non-blocking channels.

I don’t know why Sun has introduced this limitation. This article focuses on reading, but both basic IO and NIO also support writing. Since a blocing/non-blocking mode applies both to read and write directions simultaneously, then usage of Selector makes connect() and write() operations more complex. Anyway, it is the only way to have only one thread reading from several network connections.

Let’s finish for today. It’s quite easy to understand what to use. If scalability is an issue, then use “non-blocking NIO”. Otherwise, use “blocking NIO” with thread per connection. You can make those threads as daemons so they will not prevent application from termination when all other threads will stop. Another way to stop those threads is to close channels they are reading from. This will cause a read operation to interrupt with exception.

I hope I’ve shown that NIO is simple. So, don’t use NIO frameworks. They are bad.